bool[8] in uint8_t umwandeln

[N. N. (dewid2)]

Hallo zusammen,

ich möchte in meinem Code abfragen, ob ein Array nur nullen (und an 
anderer Stelle nur Einsen) enthält. Natürlich wäre es möglich  das byte 
mit 8 Operationen zusammenzusetzen, ich wollte es jedoch effizienter 
machen. Da Arrays in C ja im Speicher immer ununterbrochen angelegt 
werden (?), sollte der folgende Code die Aufgabe einfach und effizient 
übernehmen.

        bool arr[8]= {0,0,0,0,0,0,0,0};
        uint8_t *pointer;
        pointer = &arr[0];

Dies wird mir jedoch durch den Compiler versagt. Dabei sehe ich keinen 
logischen Fehler in meiner Idee. Kann mir jemand sagen wieso das nicht 
geht und wie man es ähnlich effizient machen könnte?

[Jim M. (turboj)]

Das "bool arr[8]" sind 8 Byte und nicht 8 Bit. Bei einigen Compilern 
sogar mehr, z.B. 32 Bit auf 32-bit Compilern.

Wenn man 8 Bit zu einem Byte zusammenfassen will, bräuchte man 
Bitfields. Die lassen sich aber IIRC nicht als Array ansteuern.

[N. N. (dewid2)]

Jim M. schrieb:
> Das "bool arr[8]" sind 8 Byte und nicht 8 Bit. Bei einigen Compilern
> sogar mehr, z.B. 32 Bit auf 32-bit Compilern.

Tatsache, das war mir gar nicht klar vorher. Dann werd ich meinen Code 
wohl nochmal umschreiben. Vielen Dank!

[Sven L. (sven_rvbg)]

Naja könntest Dein Array auch in einer Schleife durchlaufen und mittels 
Schiebeoperationen, die jeweiligen bits im Ausgabebyete setzen oder 
löschen

[foobar (Gast)]

> Die [Bitfields] lassen sich aber IIRC nicht als Array ansteuern.

Korrekt. Die kleinste adressierbare (notwendig für ein Array) Einheit 
ist ein Byte.

[N. N. (dewid2)]

Sven L. schrieb:
> Naja könntest Dein Array auch in einer Schleife durchlaufen und mittels
> Schiebeoperationen, die jeweiligen bits im Ausgabebyete setzen oder
> löschen

Dass das so geht war mir auch vorher klar, nur wurde dir Operation 
(mittlerweile geändert) jede Iteration meiner for(;;) Schleife 
durchlaufen, und ich hatte gehofft man könne die 8 Operationen die dein 
Vorschlag benötigt auf eine runterbrechen.



foobar schrieb:
>> Die [Bitfields] lassen sich aber IIRC nicht als Array ansteuern.
>
> Korrekt. Die kleinste adressierbare (notwendig für ein Array) Einheit
> ist ein Byte.

Das scheint universell zu sein oder? Mein 64 bit Desktop kann scheinbar 
auch einzelne bytes adressieren, ebenso wie mein MC.


Btw, wenn ein einzelner bool arr[0]=true (z.B. alle bits gesetzt) und 
uint8_t *pointer die gleiche Größe haben, ist es dann irgendwie möglich 
den pointer auf die adresse von bool zu setzen und somit dessen Wert 
(0xFF) als int auszulesen?

[Niklas G. (erlkoenig)]

N. N. schrieb:
> Das scheint universell zu sein oder? Mein 64 bit Desktop kann scheinbar
> auch einzelne bytes adressieren, ebenso wie mein MC.

C(++) definiert das Byte als die kleinste adressierbare Einheit. Ein 
char ist immer genau ein Byte groß. Die Anzahl an Bits pro Byte ist aber 
nicht festgelegt; sie ist mindestens 8 und kann über das Makro CHAR_BIT 
abgerufen werden. Auf den allermeisten Plattformen sind es aber 8. 
uint8_t ist nahezu sicher auf allen Plattformen identisch zu entweder 
unsigned char oder char oder existiert einfach nicht, falls ein char 
mehr als 8 bits hat.

N. N. schrieb:
> Btw, wenn ein einzelner bool arr[0]=true (z.B. alle bits gesetzt)
Es ist nicht festgelegt, welche Bits dann 1 sind. Meistens wird nur das 
unterste Bit genutzt.

N. N. schrieb:
> möglich
> den pointer auf die adresse von bool zu setzen und somit dessen Wert
> (0xFF) als int auszulesen?
Du kannst den Pointer auf char umcasten, was aber 
implementations-spezifisches Verhalten bewirkt und somit unportabel und 
unsauber ist. Auf int umcasten und dereferenzieren ist in C(++) 
verboten. Es kann zwar den Anschein haben zu funktionieren, kann aber 
früher oder später beliebig schief gehen (siehe auch strict aliasing).

Was hast du überhaupt vor? Möchtest du eine Datenstruktur so packen dass 
du sie abspeichern oder verschicken kannst? Dann lies mal 
Serialisierung. Mit der dort auch vorgestellten µSer-Bibliothek kann 
die anfängliche Problemstellung so gelöst werden:

#include <cstdint>
#include <iostream>
#include <uSer/uSer.hh>

int main () {
  bool array [8] = { true, false, true, false, true, false, true, false };
  uint8_t packed [1];
  uSer::serialize (packed, array);
  std::cout << "0x" << std::hex << int { packed[0] } << std::endl;  // Ausgabe 0x55
}

Die Ausgabe-Variable "packed" ist ein Array, weil µSer keinen einzelnen 
uint8_t akzeptiert. Das macht letztendlich aber kaum einen Unterschied.

[Jack (Gast)]

> ob ein Array nur nullen (und an anderer Stelle nur Einsen) enthält

Ganz fies kann das das so testen:

bool arr[8] =...;

if(!memchr(arr, true, sizeof(arr)) {
  // nur false (Nullen) in arr[]
}

if(!memchr(arr, false, sizeof(arr)) {
  // nur true (Einsen) in arr[]
}

memchr() benutzt intern eine Schleife die maximal sizeof(arr) pro 
memchr() durchlaufen wird.

[N. N. (dewid2)]

Danke für den sehr informativen Beitrag.

Niklas G. schrieb:
> Was hast du überhaupt vor?

Im Moment gar nichts. Ich setze nun die Bits klassisch mit Masken 
einzeln und es funktioniert gut wie erwartet. Die Pointerumwandlung ist 
lediglich aus Interesse. Danke auch hier für deine Tipps, ich werde mal 
überprüfen ob ein bool in meinem System auch i.A. nur über die unterste 
Stelle implementiert ist.

[guest (Gast)]

Jack schrieb:
> Ganz fies kann das das so testen:bool arr[8] =...;
>
> if(!memchr(arr, true, sizeof(arr)) {
>   // nur false (Nullen) in arr[]
> }
>
> if(!memchr(arr, false, sizeof(arr)) {
>   // nur true (Einsen) in arr[]
> }

Und im zweiten Fall fällt man dann je nach Implementierung ganz fies auf 
die Schnauze.

[Wolfgang (Gast)]

Niklas G. schrieb:
> Es ist nicht festgelegt, welche Bits dann 1 sind. Meistens wird nur das
> unterste Bit genutzt.

Festgelegt ist true als "ungleich Null", false als "gleich Null".
Alles andere kann jeder Compiler-Bauer machen wie er möchte und hat 
nichts mit C-Standard zu tun.

[Rolf M. (rmagnus)]

Wolfgang schrieb:
> Niklas G. schrieb:
>> Es ist nicht festgelegt, welche Bits dann 1 sind. Meistens wird nur das
>> unterste Bit genutzt.
>
> Festgelegt ist true als "ungleich Null", false als "gleich Null".

Nein. Wenn man einen Integer ungleich Null in einen bool konvertiert, 
kommt true raus, sonst false. Das sagt aber absolut gar nichts darüber 
aus, was bei dieser Konvertierung passiert und wie die Bits eines bool 
für true und für false aussehen müssen.

[hbl999 (Gast)]

Guck dir mal diese deklaration an:
typedef struct
{
  unsigned bit0:1;
  unsigned bla:1;
  unsigned murks:1;
  unsigned schund:3;
}tBitfeld;

Da kannst Du jetzt noch eine union drüberlegen und dann entweder als
bit (also bla=1) oder als uint8_t, uint16_t oder uint32_t
ansprechen

[Niklas Gürtler (Gast)]

hbl999 schrieb:
> Da kannst Du jetzt noch eine union drüberlegen

Das ist im C implementation defined (also unportabel) und im C++ 
komplett verboten. Also nicht die beste Vorgehensweise.

[hbl999 (Gast)]

was ist dadran unportabel`?

[Jemand (Gast)]

hbl999 schrieb:
> was ist dadran unportabel`?

C11 6.7.2.1 11:
 The order of allocation of bit-fields within a unit (high-order to
low-order  or  low-order  to  high-order)  is  implementation-defined. 
The  alignment  of  the
addressable storage unit is unspecified

[Niklas Gürtler (Gast)]

hbl999 schrieb:
> was ist dadran unportabel`?

Da Padding, Byte Order, Integer -Formate sowie die Umsetzung von 
Bitfields plattformspezifisch sind, ist das Ergebnis von solchen 
union-Konstrukten unportabel. Generell sollte man unions ausschließlich 
zum Speicher sparen nutzen, nicht für irgendwelche Konvertierungen. 
Steht auch alles detailliert in Serialisierung.

[hal9000 (Gast)]

Dummes zeug, das regelt der compilerhersteller. Wenn du das anzweifels 
darfts du gar nix mehr machen.

[Niklas Gürtler (Gast)]

hal9000 schrieb:
> Dummes zeug, das regelt der compilerhersteller. Wenn du das
> anzweifels darfts du gar nix mehr machen.

Nein, der Compiler warnt sogar teilweise in solchen Fällen, z.B. der GCC 
in Form von Strict Aliasing Verletzungen. Der Compiler kann die 
Unterschiede nicht weg-regeln ohne die Effizienz stark zu 
beeinträchtigen. Im C-Standard würde das wohl kaum so stehen wenn die 
Compiler das dann anders machen!
Und es ist richtig, dass in C wesentlich weniger erlaubt ist als oft 
angenommen. Zur Datenkonvertierung sind aber bitweise Operationen 
erlaubt und portabel.

[Niklas G. (erlkoenig)]

Hier noch ein Beispiel:

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

union U {
  struct {
    uint8_t bit0:1;
    uint8_t bla:1;
    uint8_t murks:1;
    uint8_t schund:5;
    uint64_t foo : 64;
  } tBitfield;
  struct {
    uint64_t raw [2];
  } tRaw;
};

int main () {
  union U u;
  u.tBitfield.bit0 = 0;
  u.tBitfield.bla = 0;
  u.tBitfield.murks = 0;
  u.tBitfield.schund = 0;
  u.tBitfield.foo = 1;
  printf ("%" PRIx64 "\n", u.tRaw.raw [1]);
}

Wenn man das für AMD64 kompiliert, kommt heraus:

$ gcc -m64 test.c && ./a.out 
1

Kompiliert man hingegen für IA-32:

$ gcc -m32 test.c && ./a.out 
fff36bfc00000000

Ist also plattformabhängig, d.h. unportabel. In C++ ist es wie gesagt 
ganz verboten. Der Unterschied stammt hier konkret vom Padding, denn bei 
AMD64 hat der 64bit-Integer ein 8-Byte-Alignment, es werden 7 leere 
Bytes davor eingefügt. Auf IA-32 werden nur 3 benötigt. Solche 
Unterschiede kann man teilweise mit Compiler-Optionen beeinflussen - das 
macht es aber nur noch schlimmer, wenn das Verhalten des Programms sich 
schon von Compiler-Optionen stören lässt!

Korrekt und portabel geht das nur mit Bit-Operationen. Diese werden von 
meiner µSer-Bibliothek komfortabel gekapselt, damit könnte das dann so 
aussehen:

#include <iostream>
#include <cstdint>
#include <uSer/uSer.hh>

struct tBitfield {
  USER_STRUCT(tBitfield, )
  std::uint8_t bit0;
  USER_MEM_ANNOT(bit0, uSer::Width<1>)
  std::uint8_t bla;
  USER_MEM_ANNOT(bla, uSer::Width<1>)
  std::uint8_t murks;
  USER_MEM_ANNOT(murks, uSer::Width<1>)
  std::uint8_t schund;
  USER_MEM_ANNOT(schund, uSer::Width<5>, uSer::Padding::Fixed<24+32>)
  std::uint64_t foo;
  USER_MEM_ANNOT(foo, uSer::Width<64>)

  USER_ENUM_MEM(bit0, bla, murks, schund, foo)
};

int main () {
  tBitfield bf;

  bf.bit0 = 0;
  bf.bla = 0;
  bf.murks = 0;
  bf.schund = 0;
  bf.foo = 1;
  std::uint64_t raw [2];
  uSer::serialize (raw, bf);
  std::cout << std::hex << raw [1] << std::endl;
}

Das Padding wird so gewählt dass es der AMD64-Version entspricht; somit 
ist, unabhängig von der tatsächlichen Plattform, Compiler-Optionen und 
-Version, die Ausgabe immer gleich:

$ g++ -m64 -std=c++17 test.cc && ./a.out 
1

$ g++ -m32 -std=c++17 test.cc && ./a.out 
1