www.mikrocontroller.net

Forum: Compiler & IDEs Array[8] mit 0 und 1 zu integer zb 255


Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marius Wensing (mw1987)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist doch ganz einfach...
int Integer = (Array[7] << 0) + (Array[6] << 1) + ... + (Array[1] << 6) + (Array[0] << 7)

MfG
Marius

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde das doch etwas kopiersicherer machen  ;-)
  uint8_t j, wert, Array[8]={0,0,0,0,1,1,1,1};

  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:
Array[8]={'0','0','0','0','1','1','1','1'};

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
value = 0;
for(i=0; i < sizeof(Array); ++i)
{
  value = (value << 1) | Array[i];
}

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich biete 64

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
glaube ich nicht, wo das denn?

Autor: blup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hä?
Ich glaube, du hast ein anderes C als ich.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: blup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

for( init; loop-control; inkrement )
  loop_body

ist per Definition identisch zu
  init

  while( loop-control ) {

    loop_body

    inkrement 
  }

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.
  {
    init

    while( loop-control ) {
      
      loop_body

      inkrement 
    }
  }

(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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: blup (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.