C Kommastellen verwerfen

Zitat von DerSchatten

Code

1. void Print(uint16_t num)
2. {
3. uint8_t i=0;
4. uint8_t j;
7. if (num>9999) return;
10. while (num)
11. {
12. digits[i]=num%10;
13. i++;
14. num=num/10;
15. }
16. for (j=i;j<4;j++) digits[j]=0;
17. }

Alles anzeigen

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.

Zitat von Mac Bacon

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...

Zitat von THaase

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

Zitat von DerSchatten

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?

Zitat von DerSchatten

Welche Variable ist überflüssig?
j ?

Richtig. Kannst einfach i weiterzählen, z.B. so:

Übrigens, für Zählvariablen am besten einfach immer int nehmen, das ist in der Regel die native Wortlänge der Architektur (oder weniger, vor allem bei 64bittern) und potentiell am schnellsten. Gibt natürlich Ausnahmen (8bit)

Zitat von Claus

Ganz genau betrachtet ist dann sogar am besten, uint_fast16_t Typen und Konsorten zu nehmen, die sollten dann wirklich am schnellsten sein. Ist aber vielleicht in dem Zusammenhang dann doch Korinthen und so

Trotzdem interessant, den Typ kannte ich noch nicht, klingt aber wie der "bessere int" zu dem Zweck. Wurde der auch mit C99 eingeführt?