Hallo,
Ich habe ein Array[8]=(1,1,1,1,1,1,1,1)
Als Integer soll dann 255 raus kommen.
oder so Array[0,0,0,0,1,1,1,1]
Integer=15
also von byte nach int.
Danke
Aber ich bin mir noch gar nicht so sicher, dass es wirklich das ist, was
du willst. Sind in dem Array wirklich binäre 0-en und 1-en oder sind
das ASCII-Zeichen, die über irgendeine Schnittstelle hereinkommen. Also
evtl. eher sowas:
Andi schrieb:
> Als Integer soll dann 255 raus kommen.
Wozu diese Verschwendung von 16 Bit (int)?
255 paßt bequem in ein "unsigned char" oder besser "uint8_t".
Peter
klaus schrieb:
> value = 0;>> for(i=0; i < sizeof(Array); ++i)>> {>> value = (value << 1) | Array[i];>> }
Damit fängst Du ab dem 1-ten statt dem nullten Element des Arrays an.
in der for-Schleife wäre i++ statt ++i richtig ;)
@ blup (Gast)
>Damit fängst Du ab dem 1-ten statt dem nullten Element des Arrays an.>in der for-Schleife wäre i++ statt ++i richtig ;)
Ist hier vollkommen egal, dieser Codeabschnitt wird erst NACH dem ersten
Schleifendurchlauf das erste Mal ausgeführt.
MFG
Falk
blup schrieb:
> Damit fängst Du ab dem 1-ten statt dem nullten Element des Arrays an.> in der for-Schleife wäre i++ statt ++i richtig ;)
Hast du für diese seltsame These auch eine Begründung?
ja. Je nach Compiler wird der Wert von i direkt erhöht. Das hat zur
Folge, dass der Zugriff auf Array[i] gleich beim ersten mal auf Array{1]
zeigt, statt wie gewollt auf Array[0].
Bin vor paar Jahren während ner Studienarbeit drüber gestäupert und sehr
sehr kange gesucht :)
blup schrieb:
> ja. Je nach Compiler wird der Wert von i direkt erhöht. Das hat zur> Folge, dass der Zugriff auf Array[i] gleich beim ersten mal auf Array{1]> zeigt, statt wie gewollt auf Array[0].
Ähm.
Nein. Das war dann in irgend einer anderen Sprache. Aber nicht in C.
1
for(init;loop-control;inkrement)
2
loop_body
ist per Definition identisch zu
1
init
2
3
while(loop-control){
4
5
loop_body
6
7
inkrement
8
}
und das ist so, seit der allererste C-Compiler geschrieben wurde. Das
einzige was sich mit der letzten Norm C99 verändert hat, ist ein
zusätzlicher Scope um die Schleife herum, die es erlaubt 'lokale'
Variablen innerhalb der for-Schleife bereits beim init zu benutzen.
1
{
2
init
3
4
while(loop-control){
5
6
loop_body
7
8
inkrement
9
}
10
}
(wobei die Bezeichnungen der Einzelteile der for-Schleife eher
symbolischen Wert haben und die typische Verwendung anzeigen.
> Bin vor paar Jahren während ner Studienarbeit drüber gestäupert und sehr> sehr kange gesucht :)
Du magst lange nach einem Fehler gesucht haben. Aber das war er nicht.
Es ist kaum vorstellbar, dass ein Compiler mit einem derartigen Fehler
das Compilerbaulabor unbemerkt verlässt. Jede noch so grindige
Compiler-Testsuite würde so einen Fehler in den ersten 10 Sekunden
entdecken.
Pikanterweise geht der Rat an alle, die sowohl C als auch C++
programmieren, der Version ++i den Vorzug zu geben :-)
Also
for( i=0; i < sizeof(Array); ++i )
anstelle von
for( i=0; i < sizeof(Array); i++)
Warum ist das so? Bei int oder anderen eingebauten Datentypen macht es
keinen Unterschied. Ist i aber ein anderer Datentyp, eine Klasse, kann
es einen Unterschied in der Ausführungsgeschwindigkeit geben. ++i ist
für den Compiler dann nämlich leichter zu optimieren als i++, weil man
nicht darauf angewiesen ist, dass der Compiler ein sog. Temporary (also
ein Objekt welches nur während der Auswertung existiert)
wegzuoptimieren, weil sein Wert nicht benutzt wird. Funktional sind
beide Versionen identisch. Bei eingebauten Datentypen sowieso, bei
eigenen Datentypen sollten es auch so sein, wenn präfix und postfix ++
richtig und konsistent implementiert sind.
blup schrieb:
> ja. Je nach Compiler wird der Wert von i direkt erhöht. Das hat zur> Folge, dass der Zugriff auf Array[i] gleich beim ersten mal auf Array{1]> zeigt, statt wie gewollt auf Array[0].
Ein solcher Compiler wäre aber ziemlich kaputt. i++ und ++i
unterscheiden sich einzig durch ihren Rückgabewert, der in der
for-Schleife oben überhaupt nicht ausgewertet wird, also darf da nichts
untersschiedliches rauskommen.
> Bin vor paar Jahren während ner Studienarbeit drüber gestäupert und sehr> sehr kange gesucht :)
War das wirklich genau diese Situation?
> Pikanterweise geht der Rat an alle, die sowohl C als auch C++> programmieren, der Version ++i den Vorzug zu geben :-)
In C++ klar, aber bei C habe ich diesen Rat noch nie gehört, denn da
kann man sich ja gar keinen eigenen Operator++ basteln.
Auch in C++ bietet es seltener einen Vorteil, als die meisten denken.
Die häufigsten Anwendungsfälle für den benutzerdefinierten Operator++
sind wohl Iteratoren und Smart-Pointer. Beide sind in der Regel als
Templates ausgeführt, wodurch sie eigentlich immer im Header
implementiert sind. Prima für's inlining von Operator++ und
Kopierkonstruktor. Die sind zudem meist sehr einfach gestrickt. Das sind
ideale Voraussetzungen für die Optimierung.
Rolf Magnus schrieb:
>> Pikanterweise geht der Rat an alle, die sowohl C als auch C++>> programmieren, der Version ++i den Vorzug zu geben :-)>> In C++ klar, aber bei C habe ich diesen Rat noch nie gehört, denn da> kann man sich ja gar keinen eigenen Operator++ basteln.
Es geht darum, sich einfach daran zu gewöhnen, automatisch immer die
prefäx Version zu benutzen. Für reine C Programmierer ist das nicht
relevant, wie du richtig anmerkst, und wie ich hoffte das es aus dem
Satzteil "die sowohl C als auch C++ programmieren" hervorgeht.
Karl heinz Buchegger schrieb:
> Für reine C Programmierer ist das nicht relevant, wie du richtig> anmerkst, und wie ich hoffte das es aus dem Satzteil "die sowohl C als> auch C++ programmieren" hervorgeht.
An sich geht das daraus hervor. Ich hab's aber trotzdem geschafft, es
mißzuverstehen als "sowohl alle C-Programmierer, als auch alle
C++-Programmierer".
Und wieder was dazu gelernt. Es war wohl tatsächlich das wegoptimieren.
Es war ein struct- oder Objekt-Pointer (so genau weiß ichs nicht mehr).
Habe gerade noch mal ne Testdatei geschrieben, das Verhalten ist
identisch, wie hier bereits erläutert. :)
Somit entschuldige ich mich für die falsche Behauptung und danke für die
neue Erkenntnis. Dann kann ich also wieder ruhig auf die präfix-Notation
wechseln, die mir alleine schon optisch lieber ist.
MfG aus Stuttgart
Thread beobachten
Seitenaufteilung abschalten