Geradzahligkeit ermitteln
-
Und wie langweilig

camper hat wie immer recht. dumme sache das. mach mal fehler!!PUBLIC _is_even ; Function compile flags: /Ogtpy ; File d:\code\testili\testili\extern.cpp ; COMDAT _is_even _TEXT SEGMENT _num$ = 8 ; size = 4 _is_even PROC ; COMDAT ; 2 : return num%2u == 0; mov eax, DWORD PTR _num$[esp-4] not eax and eax, 1 ; 3 : } ret 0 _is_even ENDP _TEXT ENDS PUBLIC _is_even2 ; Function compile flags: /Ogtpy ; COMDAT _is_even2 _TEXT SEGMENT _num$ = 8 ; size = 4 _is_even2 PROC ; COMDAT ; 6 : return !(num&1); mov eax, DWORD PTR _num$[esp-4] not eax and eax, 1 ; 7 : } ret 0 _is_even2 ENDP _TEXT ENDSsehr dummer vc++ aber. denn er koennte eigentlich wissen dass 2 nicht negativ sein kann...
-
Wirklich sehr dumm, dem VC++ hätte ich schon etwas mehr zugetraut...
Wie ist das eigentlich mit anderen Operationen, z.B. Bitshift bzw. Multiplikation/Division mit 2? Das wäre ja das Letzte, wenn man Performanceeinbusse in Kauf nehmen müsste, weil man keine Bitschiebereien einsetzt.
-
Shade Of Mine schrieb:
sehr dummer vc++ aber. denn er koennte eigentlich wissen dass 2 nicht negativ sein kann...
Das weiß er schon, er weiß aber nicht -kann nicht wissen - dass num nicht negativ sein kann (das kann es ja sehr wohl). 2u deshalb nur, um den ersten Operanden implizit in unsigned zu konvertieren statt einen cast zu bemühen. vc hat ja recht insofern, dass vorzeichenbehaftete Integer-Division, wenn man sie mit shifts baut, für negative Werte anders ausgeführt werden muss (weil arithmetisches Rechtsshift stets abrundet, Division durch eine dagegen immer Richtung 0 bei x86&co) - daher die Unterscheidung. Das ist bei gcc auch nicht anders - nur ist dort der Optimierer offenbar clever genug zu erkennen, dass das in diesem speziellen Fall unerheblich ist. Bleibt noch zu erwähnen für diejenigen, die Assembler nicht verstehen, dass der Compiler audacias Variante in folgendes Äquivalent (2er-Komplement!) transformiert:
inline bool isEven (int num) { return ~num & 1; }