Nein, eine Multiplikation mit 257 war nicht gemeint.
Der TO will einen 16-Bit Wert aus zwei 8-Bit Werten zusammenbastelt, die
über den UART empfangen wurden. Und da macht es eben einen Unterschied,
wo LSB und MSB im 16-Bit Ergebnis landen.
Johann L. schrieb:> Nein, eine Multiplikation mit 257 war nicht gemeint.>> Der TO will einen 16-Bit Wert aus zwei 8-Bit Werten zusammenbastelt, die> über den UART empfangen wurden. Und da macht es eben einen Unterschied,> wo LSB und MSB im 16-Bit Ergebnis landen.
Ach so. Also sowas hier dann:
1
uint16_tuart_rx16(void)
2
{
3
uint8_tlo_byte=uart_rx();
4
uint8_thi_byte=uart_rx();
5
return(hi_byte<<8)|lo_byte;
6
}
Und schon stellt sich die ursprüngliche Frage gar nicht mehr, weil man
saubere Sequence Points hat.
Für mich ein typischer Fall von "Quetsch nicht so viel Code in eine
Zeile, dann lösen sich viele Probleme von ganz alleine".
Johann L. schrieb:> Mit Optimierung hat das nix zu tun
In der Vorstellung mancher Menschen schon:
"Wenn ich möglichst wenig Code schreibe, dann ist das optimal. Also
quetsche ich möglichst viele Anweisungen in eine Zeile, anstatt das
Ganze auszuschreiben."
Mark B. schrieb:> "Wenn ich möglichst wenig Code schreibe, dann ist das optimal. Also> quetsche ich möglichst viele Anweisungen in eine Zeile, anstatt das> Ganze auszuschreiben."
Der Ausdruck enthält gerade einmal zwei Operationen (| und <<). Das ist
IMHO nicht gequetscht, sondern die ganz natürliche Schreibweise für so
etwas. Etwa vergleichbar wäre
1
returngain*x+offset;
Das würde auch niemand (außer den BASCOM-Programmierern ;-)) in mehrere
Zeilen aufdröseln:
1
intgainedValue=gain*x;// unnötig
2
returngainedValue+offset;// kompliziert
Der einzige Grund, warum man die Codezeile
1
returnuart_rx()|(uart_rx()<<8);
in zwei Anweisungen aufsplitten muss, ist der mehrfache Aufruf der
nebeneffektbehafteten Funktion uart_rx, deren Aufrufreihenfolge sonst
nicht definiert ist.
>> in zwei Anweisungen aufsplitten muss, ist der mehrfache Aufruf der> nebeneffektbehafteten Funktion uart_rx, deren Aufrufreihenfolge sonst> nicht definiert ist.
Und der Grund warum dies nicht getan wurde ist, dass der Programmierer
meint dies in eine Zeile quetschen zu müssen.
q.e.d.
Mark B. schrieb:> Und der Grund warum dies nicht getan wurde ist, dass der Programmierer> meint dies in eine Zeile quetschen zu müssen.
Ich glaube nicht, dass er unter irgendwelchen Zwängen steht.
Deswegen hat er ja nachgefragt, ob man das so machen kann, und nach den
ersten beiden Antworten auch sofort eingesehen, dass es so nicht geht.
Kritisieren solltest du also nicht ihn, sondern diejenigen, die solche
Konstrukte in ihren Code einbauen, ohne sich vorher zu vergewissern,
dass sie korrekt sind.
Yalu X. schrieb:> ohne sich vorher zu vergewissern,> dass sie korrekt sind.
Und wenn man sich bei einem Konstrukt erst vergewissern muss, dass es
korrekt ist, ist es zu kompliziert.
@ Yalu X. (yalu) (Moderator)
>Deswegen hat er ja nachgefragt, ob man das so machen kann, und nach den>ersten beiden Antworten auch sofort eingesehen, dass es so nicht geht.
Ein guter Compiler sollte da mindestens eine Warung ausspucken. Gute
Programmiersprachen lassen solche Konstrukte gar nicht erst zu ;-)
Tom schrieb:> Und wenn man sich bei einem Konstrukt erst vergewissern muss, dass es> korrekt ist, ist es zu kompliziert.
Wem das zu kompliziert ist, der sollte Bascom benutzen. ;-)
Falk B. schrieb:> Ein guter Compiler sollte da mindestens eine Warung ausspucken.
GCC und Clang tun das jedenfalls nicht, vemutlich deswegen, weil der
Compiler i.Allg. gar nicht erkennen kann, ob eine Funktion Nebeneffekte
hat (bspw. dann, wenn er nur die Funktionssignatur, aber nicht deren
Implementation sieht).
Jörg W. schrieb:> Wem das zu kompliziert ist, der sollte Bascom benutzen. ;-)
Daran hat ganz sicher auch Falk gedacht, als er schrieb:
Falk B. schrieb:> Gute Programmiersprachen lassen solche Konstrukte gar nicht erst zu> ;-)
So arg viel mehr Programmiersprachen, die keine zwei Funktionsaufrufe in
einem Ausdruck zulassen, gibt es nämlich gar nicht¹.
Auch von mir gibt's noch einen Augenzwinker-Smiley dazu: ;-)
———————————
¹) Es gibt aber immerhin welche (z.B. Java), bei denen im Gegensatz zu C
die Auswertereihenfolge vollständig spezifiziert ist. Da wäre dann
auch der Ausdruck des TE korrekt.