Nog heel veel meer ontwerptips en domme fouten

Een C compiler die geen K&R of ANSI-C doet is geen C-compiler. Het is fijn dat je dan een workaround met haakjes kunt doen, maar de compiler bevat op dat moment gewoon een bug die gefixt moet worden.

Niet erg klantgericht ingesteld, he?...
Er zijn nu eenmaal compilers die afwijken. Als je dan iedere keer zegt 'koop maar een andere, ik doe er niks aan', dan houd je niet veel klanten over...
Terwijl een simpele syntaxverandering de boel op kan lossen. Ik heb nu eenmaal geen invloed op welke compiler klanten/dealers gebruiken...

Om over twee haakjes (die verder niets aan de code veranderen, maar alleen verduidelijken) ruzie met klanten te gaan maken vind ik zinloos.

Het gaat niet om ruzie met klanten. Als die compiler stuk is, dan werk je daaromheen, dat begrijp ik ook.

Ik moest een keer iets doen met een specifieke C-compiler die de mist in ging met switch-statements. Viel op een bepaalde manier (na inspectie van de resulterende assembly) omheen te werken, dus op die manier het probleem maar opgelost, immers moet het product van de klant zsm werken.
Maar... tevens bij de fabrikant van de compiler een bug-report ingediend.

Als jij standaard overbodig veel haakjes gaat gebruiken, niet vanwege leesbaarheid maar puur met als reden dat de compiler het misschien niet doet zoals het hoort... dat is gewoon een heel ander verhaal.
Dan kun je net zo goed in elke functie je by-value doorgegeven parameters eerst maar even voor de zekerheid in een andere variabele zetten, voor het geval dat de compiler toch per ongeluk veranderingen teruggeeft aan je aanroepende code. Slaat ook helemaal nergens op.

Of wat minder exotisch: mensen die menen dat je er niet vanuit mag gaan dat de rechter operand in een logic-OR (||) of logic-AND (&&) niet wordt geëvalueerd als de linker operand reeds respectievelijk true of false blijkt.

Voor al die dingen geldt: het is gewoon vastgelegd dat de compiler zo MOET werken. Doet hij dat niet, dan is hij stuk.

Op 19 juli 2019 08:13:44 schreef rew:
[...]
Er staat (R1+R2)/ R2 x 1.204 en dat is correct. Vermenigvuldigen en delen wordt gewoon van links naar rechts gedaan dus de uitkomst van R1+R2 deel je door R2 en de uitkomst daarvan vermenigvuldig je met 1.204. Zo je wilt: ((R1+R2)/ R2) x 1.204, maar dat bevalt volgens de normale rekenregels onnodige haakjes.

Ik zou het weer anders opschrijven:

(R1+R2 / R2) x 1.204

Mogelijk zit ik er volkomen naast, rekenen is niet mijn sterkste kant..
Maar ik moet het toch even kwijt.

Op 19 juli 2019 23:34:46 schreef Martin V:
(R1+R2 / R2) x 1.204

Nu moet je dus eerst R2 delen door R2. De uitkomst wordt opgeteld bij R1, en daar het resultaat van gaat nog even maal 1204.

Lijkt me niet wat je wilt, want dan had je de formule al meteen kunnen schrijven als (R1+1) x 1204

Op 19 juli 2019 23:34:46 schreef Martin V: (R1+R2 / R2) x 1.204

Dat geeft wel echt een ander resultaat!

Als je dit in integers zou berekenen, wordt de volgorde van de berekeningen wel belangrijk voor een nauwkeurigheid van je resultaat; eerst delen en dan vermenigvuldigen is dan een slecht idee, omdat je bij het delen resolutie weggooit.

Is niet altijd een goede oplossing. Als je begint met een groot getal, dan krijg je overflow na vermenigvuldiging en moet je dus wel beginnen met delen.

Ja, dat had ik er eigenlijk nog bij willen schrijven; wel oppassen dat je niet uit het bereik van je integers loopt. Als de deler een constante is (zoals vaak bij het omrekenen van ADC samples e.d.), kun je de deling in 2 stukken splitsen; eerst wat nodig is om nooit uit het bereik te lopen, en de rest aan het eind, en bij voorkeur doe je die eerste (als het kan beide) dan met een bitshift, dat is eigenlijk altijd significant sneller dan een integer deling.

Veel moderne microcontrollers (zoals de STM32F4 die ik veel gebruik; die gaat toch al een tijdje mee) hebben dedicated floating-point hardware aan boord. Een vermenigvuldiging van 2 single precision floats kost 1 cycle, aangenomen dat de operants als geladen zijn, en een deling 14 cycles. Een integer bitshift kost 1 cycle (ongeacht de shift count), maar een integer deling kost 2 tot 12 cycles, afhankelijk van de waarde van de deler.

Het verschil tussen de worst-case 12 cycles van een integer deling, en de vaste 14 cycles van een floating point is erg klein. Zelfs als je de (2+12)/2 = 7 cycles als gemiddelde neemt voor integer delingen, scheelt het maar een factor 2 op die ene instructie. Je kunt je dan afvragen of het de moeite loont om nog met fixed-point te werken.

Voor controllers zonder floating-point hardware (zoals oude 8-bitters) ligt dat natuurlijk anders.

M'n ex-vriendin kwam vandaag aanlopen met zo'n solar lampje. Nieuw gekocht, had al een jaar ongebruikt gelegen want hij "deed het niet".

Ik: "Ik kijk zo wel even. Kan nooit moeilijk zijn te ontdekken wat er aan mankeert. Die dingen zit bijna niks in: een zonnecel, accu, LEDje en scha...."
Inderdaad: een ON/OFF schakelaar. Had 't zelf ook bijna over het hoofd gezien.

Van mij mogen fabrikanten van solar lampjes die schakelaars wel weg laten...

In theorie gaan ze eerder stuk omdat de hele winter de accu zo goed als leeg is, je moet ze dan ook voor gebruik opladen met de knop op off (al kom ik ze tegen met de schakelaar aan de batterij) en daarna pas aanzetten, en in de winter naar binnen.

Meestal gaat het printje eerder...

met een pir op die dingen werkt beter, dan kom je met een accu in de winter nog wel rond. verders is het ontwerp echt in een warm land gedaan, een accucel laden bij 0 graden is al 1 ding, laat staan 8 uur licht tegen 16 uur donker..

Holy overflow batman, tijd voor een nieuw deel

[Bericht gewijzigd door Sine op dinsdag 13 augustus 2019 09:45:25 (34%)