Vergleichen mit GCC - Was geht "am Besten" ?

1

if(foo != 1) { ...

-> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu 
tun hat.

Deine restlichen Alternativen hängen vom Variablentyp ab, da kann man 
nichts zu sagen.

Maik F. schrieb:
>

1

if(foo != 1) { ...

> -> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu
> tun hat.

Anscheinend geht es ihm nur um 0 oder 1, also binär. Ansonsten würde es 
nicht viel Sinn ergeben.

Hallo,

Grundsätzlich sollte man dem Compiler die Sache so klar wie möglich 
beibringen. D.h. ich erwarte eignetlich, dass er (i == 0) und (!i) in 
den gleichen Assembler umsetzt.
Wenn man (!(i>0)) schreibt nötig man den Compiler u.U. wirklich einen 
compare einzubauen, muss aber nicht sein.
Um sicher zu sein, hilft nur der Blick ins Assemblerlisting.

Gruß
Patrick

Patrick Markl schrieb:

> Wenn man (!(i>0)) schreibt nötig man den Compiler u.U. wirklich einen

Ganz abgesehen davon, dass !(i>0) je nach Datentyp nicht dasselbe ist 
wie i==0

Patrick Markl schrieb:
> D.h. ich erwarte eignetlich, dass er (i == 0) und (!i) in
> den gleichen Assembler umsetzt.

Yep.  Daher sollte man die Form !i auch der Lesbarkeit halber nur
dann verwenden, wenn i tatsächlich einen Boolean repräsentiert
(egal, ob nun vom Typ `int' oder C99-mäßig vom Typ `bool').

N'abend,

es ist ja so: Abh. vom Problem bzw. Algorithmus macht es durchaus Sinn 
aus Gründen der Lesbarkeit des Codes ein "kompliziertes" Konstrukt z.B.

1

if(!(foo > 0)) { ...

zu schreiben.

Mir ist auch klar, dass meine o.g. Beispiele von Datentyp (bin mal von 
uint8_t ausgegangen) abhängen.

> if(foo != 1) { ...
> -> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu
> tun hat.

Ich dachte hier z.B. an eine Variable (uint8_t) die 0 wird wenn 
irgendwas passiert. Im Normalfall ist die eben 1 ...

> Um sicher zu sein, hilft nur der Blick ins Assemblerlisting.

Habe ich bisher nie gemacht... Ich seh mir das mal an ...

Alles klar soweit - danker erstmal!

Gruß und schönen Abend

Andreas

Wenn man das Letzte rauskitzeln will, dann kann es nebem dem Unterschied 
in der Bedeutung durchaus einen Unterschied machen, ob man
  if (x != 0)
oder
  if (x == 1)
schreibt. Denn es kann sein, dass aus der vorherigen Operation heraus 
der Zustand "ist Null" noch im Statusregister steht. Ein Compiler ist 
manchmal in der Lage, dies entsprechend auszunutzen und kann dann in der 
ersten Variante den Vergleich einsparen. In der zweiten Variante nur, 
wenn er genau weiss, dass nur die Werte 0 und 1 überhaupt möglich ist 
(GCC kann sowas tatsächlich rauskriegen, bei anderen 
Mikrocontroller-Compilern würde ich darauf nicht wetten).

Je nach Architektur kann ein Vergleich mit 0 ausserdem billiger sein, 
als einer mit einem anderen Wert. Dies trifft auch auf AVR zu, nicht 
zuletzt dann wenn der Wert in einem der ersten 16 Register liegt.

Ob du allerdings
 if (x > 0)
oder
 if (!(x <= 0))
schreibst, ist üblicherweise egal. Die Negation des zweiten Ausdrucks 
wird ein nicht völlig primitiver Compiler in die Sprungbedingung 
einbauen. Wobei er das bei vorzeichenlosem Datentyp oder als 
vorzeichenlos bekanntem Wertebereich u.U. in ==0 umwandelt, weil nicht 
selten billiger.

Uboot- Stocki schrieb:

>> if(foo != 1) { ...
>> -> Da musst du mir mal erklären, was das mit einem Vergleich mit 0 zu
>> tun hat.
>
> Ich dachte hier z.B. an eine Variable (uint8_t) die 0 wird wenn
> irgendwas passiert. Im Normalfall ist die eben 1 ...

Das ist unklug.
Versuch bei solchen Dingen immer alles in das Schema zu packen:
Es gibt nur 0 oder nicht 0. (1 ist nicht 0, aber 5 ist auch nicht 0). 
Wobei 0 für "nichts ist passiert" steht.

Selbst wenn es zur Zeit in einer Variablen nur 0 oder 1 geben kann, 
geschieht es in der Praxis immer wieder, dass es plötzlich auch noch 2 
geben kann (zb als zusätzlichen Fehlercode). Wohl demjenigen, der 
vorausschauend gearbeitet hat und das berücksichtigt hat.
Dann gibt es plötzliche einen riesen Unterschied zwischen

1

  ....

2

  if( x == 0 ) {

3

    // kein Fehler passiert

4

  }

und

1

  ...

2

  if( x != 1 ) {

3

    // kein Fehler passiert

4

  }

Das Erste funktioniert weiter wie gehabt, das Zweite erfordert 
Anpassarbeit.