"seltsames" Verhalten im if

[Fragender (Gast)]

Folgendes Szenario:

32bit Controller.

1. c-File

unsigned char val1 = 0;
unsigned char val2 = 0xFF;

2. c-File

extern unsigned char val1;
extern unsigned char val2;

if (val1 == ~val2)
{ STATEMENT_1 } else {STATEMENT_2}

Nach Abarbeiten des if stell ich fest dass STATEMENT_2 erreicht wurde.
Gewünscht hätt ich mir natürlich STATEMENT_1.
Durch wildes rumgecaste kann ich das Problem beheben.

Kann mir wer sagen wo mein Denkfehler ist?
Ich hab eine Vermutung, will aber hier nicht vorgreifen :-)

[Pete K. (pete77)]

Wie ist denn unsigned char bei Deinem unbekannten Compiler definiert?
Als 32bit? Dann reichen 0xFF wohl nicht.

[Kaj (Gast)]

Einfach mal die Warnungen einschalten...

Warnung: comparison of promoted ~unsigned with unsigned [-Wsign-compare]
     if (val1 == ~val2) {
              ^~

[Yalu X. (yalu) (Moderator)]

val1 = 0
~val2 = 0xffffff00

(wegen Integer-Promotion)

Edit: Vielleicht wolltest du schreiben:

  if (val1 == (unsigned char)~val2)
    ...

Damit verschwindet auch die Warnung des Compilers.

[Johann L. (gjlayde)]

Fragender schrieb:
>

> if (val1 == ~val2)
> { STATEMENT_1 } else {STATEMENT_2}
>

Kannst du vereinfachen zu:

{STATEMENT_2}

denn der 1. Zweig wird nie ausgeführt da die Bedingung immer false ist.

[Yalu X. (yalu) (Moderator)]

Johann L. schrieb:
>> if (val1 == ~val2)
>> { STATEMENT_1 } else {STATEMENT_2}
>>
> Kannst du vereinfachen zu:
> {STATEMENT_2}
> denn der 1. Zweig wird nie ausgeführt da die Bedingung immer false ist.

Sollte man Optimierungen nicht lieber dem Compiler überlassen? ;-)

[Rolf M. (rmagnus)]

Yalu X. schrieb:
> Sollte man Optimierungen nicht lieber dem Compiler überlassen? ;-)

Naja, man muss ja nicht unbedingt zusätzliche unnötige Dinge einbauen, 
nur damit der Optimizer was zu tun hat.

[Carl D. (jcw2)]

Rolf M. schrieb:
> Yalu X. schrieb:
>> Sollte man Optimierungen nicht lieber dem Compiler überlassen? ;-)
>
> Naja, man muss ja nicht unbedingt zusätzliche unnötige Dinge einbauen,
> nur damit der Optimizer was zu tun hat.

Vielleicht hat man ja eine Source für 2 verschiedene Hardware-Versionen, 
dann ist es doch schön wenn der Compiler den nicht benötigten Teil 
rückstandsfrei entsorgt. Wenn z.B. die Datenpins eines LCD entweder 
nebeneinander am selben Port, oder wild verstreuht vorliegen und im 
ersten Fall offensichtlich eine optimierte Implementierung möglich ist.

Und nein, der Preprocesser ist nicht für alles die richtige Lösung.

[Nop (Gast)]

Carl D. schrieb:

> Und nein, der Preprocesser ist nicht für alles die richtige Lösung.

Wie jetzt, ich dachte, der sei Turing-vollständig? ;-)