Die zweite Zählvariable ist auf jeden Fall überflüssig, aber das ist ne Kleinigkeit. Vielleicht generell -- ich finde so eine Mischung deutsch/englisch wird schnell unübersichtlich. Aber das ist wohl auch Geschmackssache.
In C ist das Ergebnis der Operation "Negativer Wert nach rechts geshiftet" undefiniert. Das wird hier vermutlich nicht das Problem sein, kann einem aber den Tag verderben. [AxelStoll] Muss man nur wissen [/AxelStoll].
Zeile 131 wäre also eine mögliche Problemstelle? Kann es passieren, dass das Vorzeichenbit mitgeschoben wird? Nett...
Der Code kann nicht der selbe sein .... man müsste sich aber mal den output anschauen um zu sehen was schneller ist ... bne/beq bzw. jmp sind recht lahm wenn ich mich da recht erinnere ...
Prinzipiell kann der schon derselbe sein, wenn der Compiler für den einen Teilausdruck erkennt, dass die Wertemenge nur 2 Elemente hat. Habe jetzt gar nicht darauf geachtet, auf welcher Architektur wir hier sind -- aber Branches sollen lahm sein? Das wäre schlecht. Kann man (f<0) überhaupt ohne Branch auswerten? Würde mich wundern, und dann erstmal mit weiteren Rechnungen anzufangen, anstatt nach dem Branch direkt die gewünschte Operation auszuführen ist sicher nicht besser
Die Diskussion über Runden und/oder Nachkommastellen abschneiden scheint aber eh unpassend, in dem ganzen Code gibt es ja nur Ganzzahlen
Mit int32_t funktioniert.
Wenn ich das jetzt richtig verstanden habe müsste damit wohl auch das Problem der zu lange angezeigten 0 gelöst sein, oder?