Syntax unterscheidung gerade oder ungerade

if(i % 2)
  // ungerade
else
  // gerade

Der Modulo-Operator gibt den Rest einer Ganzzahldivision aus.

Wird eine Zahl mit 2 dividiert und der Rest ist 0 -> gerade
Ist der Rest 1 -> ungerade

ich meine durch 2 dividiert...

oje, haja klar! - modulo, da war doch was! - hab ich voll verdrängt 
rolleyes

Danke!

ich glaube gandalf und sascha haben die gleiche Idee


@stefan - kannst du mir mal "Dein" define erläutern - verstehe das 
leider nicht :(

Die version von Stefan B. ist wesentlich besser.
im prinzip musst du ja nur prüfen ob das LSB(niederwertigste Bit) 1 oder 
0 ist.
if( (x&1) == 0){
// gerade
}
else{
// ungerade
}
ist das gleiche nur als if-bedingung geschrieben

lg Azrael

Wenn es unsigned char, gibt das unterste Bit Aufschluß

// testen ob unterstes Bit gesetzt, wenn ja, ist term boolisch wahr
if (variable & 1)
{
   - ungerade
} else
{
   - gerade
}


Und das Zweierkomplement bei negativen, signed chars dürfte einem keinen 
Strich durch die Rechnung machen - das war doch: negiert plus eins - 
oder !?

neg = (~pos) + 1;

Bei negativen Werten geht das auch und übrigens nicht nur für unsigned 
char, sondern alle integer-typen, also char, short, long, long long usw. 
und eben auch signed.

Bei float-Typen (float, double) geht das so nicht.

okay alles klar - dürfte schneller als die modulo gehen!

Danke an Euch alle!!!

Ich habe übrigens auch schon häufig gesehen, dass der Compiler Moduli 
mit Zweierpotenzen in entsprechende Und-Verknüpfungen optimiert, aber 
das hängt mit Sicherheit von Compiler und Architektur ab.

@Thomas:

Sag' ich doch: Negiert plus 1

@Florian: ... und davon, ob mit oder ohne Vorzeichen. Bei Datentypen mit 
Vorzeichen ist es deutlich komplizierter.

wieso ist eine Bitmaskierung nicht ratsam @Andreas?

Es ist m.M.n. mind. genau so verständlich wie die modulo.

Ich selbst sehen darin keinen Unterschied, wenn man einen "schlechten" 
Compiler hat der das nicht "wegoptimiert" dauert es deutlich länger - 
somit ist es für mich eine potentielle Bremsstelle im code, oder?

Dummerweise ist -3 % 2 aber nicht 1, sondern -1.

<sarkasmus>

Dann nimmt man eben die unverschleierte Konstruktion

if ( ( ( x % 2 ) == 1 ) || ( ( x % 2 ) == -1 ) )

anstatt

if ( x & 1 )

</sarkasmus>

>Weil es die Methode verschleiert

...wofür es Kommentare gibt

> Oder willst du auf etwas anderes hinaus?

Ich will darauf hinaus, das kein Compiler bei Typen mit Vorzeichen (x % 
2) einfach zu (x & 1) optimieren darf. Dividieren muss er zwar nicht, 
aber bissel komplizierter ist es dennoch. Bei der Division sieht das 
beispielsweise für x / (2**n) so aus:

1

if (x < 0)

2

    x += (2**N)-1;

3

return x >> N;

P.S.: Wer das 2er Komplement nicht kennt, ist meiner Quelltexte nicht 
würdig ;-)

@A.K.:
Auf vielen Architekturen gibt es die Unterscheidung zwischen logical 
shift right und artihmetic shift right. Bei letzterem wird dann von 
links nicht mit Nullen, sondern dem ursprünglichen höchsten Bit gefüllt. 
Dann bleibt das ganze wieder konsistent.

Der C-Compiler allerdings macht immer ein logical shift right, so dass 
Dein Konstrukt notwendig wäre, allerdings ist es vermutlich besser 
tatsächlich so was wie

y = x / ( 1 << N )

zu schreiben, da der Compiler das vermutlich zu

asr x, N

vereinfachen würde.

> Bei letzterem wird dann von links nicht mit Nullen,
> sondern dem ursprünglichen höchsten Bit gefüllt.
> Dann bleibt das ganze wieder konsistent.

Nein. Die C Division rundet gegen Null, der arithmetische Shift gegen 
Minus Unendlich.

> Glück gehabt: noch mal nach oben gescrollt ergibt, dass
> von einem unsigned char die Rede ist. -3 ist daher aussen vor

Pech gehabt. Die integer promotion von C bringt es mit sich, dass solche 
Ausdrücke als "int" gerechnet werden.

Wenn der Compiler das erst zu 16 oder 32 Bits erweitert, dann geht ihm 
auf dem Weg allzu leicht die Information verloren, dass negative Werte 
nicht vorkommen können.

Und genau das passiert mindestens bei den PC-Compilern von Microsoft und 
Walter Bright (Digital Mars).