Array[8] mit 0 und 1 zu integer zb 255

Ist doch ganz einfach...

1

int Integer = (Array[7] << 0) + (Array[6] << 1) + ... + (Array[1] << 6) + (Array[0] << 7)

MfG
Marius

Ich würde das doch etwas kopiersicherer machen  ;-)

1

  uint8_t j, wert, Array[8]={0,0,0,0,1,1,1,1};

2

3

  for (wert=0, j=0; j<8; j++, wert<<=1) if(Array[j]) wert+=1;

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:

1

Array[8]={'0','0','0','0','1','1','1','1'};

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

>> Als Integer soll dann 255 raus kommen.
> Wozu diese Verschwendung von 16 Bit (int)?
Meine Integer haben sogar 32 Bits... ;-)

glaube ich nicht, wo das denn?

hä?
Ich glaube, du hast ein anderes C als ich.

@  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:
> 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.

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.