Datentyp mit 3 Bytes

Tachyon

~fricky schrieb:

Tachyon schrieb:
typedef unsigned char three_byte_type[3];
^^das ist doof, weil's trotzdem ein array bleibt.
three_byte_type a = 1; <-- error: array initialisation needs curly braces

Nö, ist es nicht. Wenn der das Ganze als eine 24-Bit Zahl behandeln will, kommt er eh nicht drum herum, passende getter/setter zu implementieren. Und das Array ist einfacher geschlossen auf 0 zu setzen, als ein Struct.

Tachyon schrieb:

Wenn der das Ganze als eine 24-Bit Zahl behandeln will, kommt er eh nicht drum herum, passende getter/setter zu implementieren.

doch, mit 'nem bitfield kommt er drum herum:

typedef struct three
{
  int val :24;
} three_t;
...
three_t a;
a.val = 0xffffff; // <-- -1
...

columbus

~fricky schrieb:

Tachyon schrieb:

Wenn der das Ganze als eine 24-Bit Zahl behandeln will, kommt er eh nicht drum herum, passende getter/setter zu implementieren.

doch, mit 'nem bitfield kommt er drum herum:
typedef struct three
{
  int val :24;
} three_t;
...
three_t a;
a.val = 0xffffff; // <-- -1
...

Ja, an sowas habe ich auch gedacht. Ich habe es ausprobiert und es läuft. Ich hoffe ich handle mir da keinen späteren Komplikationen ein? Oder irgend welche Nachteile.

Aber vielen Dank bis hierhin erstmal. Falls jemand noch eine Idee hat?

Gruss Christian

wie sieht aus?

int i= sizeof(three_t);

camper

columbus schrieb:

~fricky schrieb:
Tachyon schrieb:

Wenn der das Ganze als eine 24-Bit Zahl behandeln will, kommt er eh nicht drum herum, passende getter/setter zu implementieren.

doch, mit 'nem bitfield kommt er drum herum:
typedef struct three
{
  int val :24;
} three_t;
...
three_t a;
a.val = 0xffffff; // <-- -1
...
Ja, an sowas habe ich auch gedacht. Ich habe es ausprobiert und es läuft. Ich hoffe ich handle mir da keinen späteren Komplikationen ein? Oder irgend welche Nachteile.

Aber vielen Dank bis hierhin erstmal. Falls jemand noch eine Idee hat?

Gruss Christian

Dieses bit-Feld ist je nach Implementation vorzeichenbehaftet oder vorzeichenlos. Da du ausdrücklich eine vorzeichenlose Zahl benötigst, sollte das Bit-Feld daher mit unsigned deklariert werden.

typedef struct three
{
  unsigned val :24;
} three_t;

Ansonsten ist Größe und Ausrichtung der Struktur nicht ausdrücklich festgelegt (aber natürlich Größe >= 3 für CHAR_BIT==8), praktisch wird es für gewöhnlich die des Typs sein, der für die Deklaration des Bit-Feldes verwendet wurde.

Ein mögliches Problem könnte werden, wenn man auf Systemen kompiliert wo ein int nicht >= 24 Bit breit ist. Und da so Dinge wie:

typedef struct three
{
  unsigned long val :24;
} three_t;

auch nicht einheitlich gültig sind...

A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type.

pointercrash**

Tim schrieb:

Ein mögliches Problem könnte werden, wenn man auf Systemen kompiliert wo ein int nicht >= 24 Bit breit ist. Und da so Dinge wie:
typedef struct three
{
  unsigned long val :24;
} three_t;
auch nicht einheitlich gültig sind...

A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type.

Öhhhmm, was ist denn der Unterschied zwischen qualified und unqualified

Aber jenseits der "Der Standard sagt"- Tiraden habe ich die Erfahrung gemacht, daß Bitfields immer als Bits aligned Byte aligned Word aligned Dword usw. implementiert sind, was ja auch irgendwie einleuchtet, denn wie soll ein kurios typisiertes Bitfield Sinn machen?

pointercrash() schrieb:

Öhhhmm, was ist denn der Unterschied zwischen qualified und unqualified

Beispielweise
unqualified: int
qualified: const int, wobei const der type qualifier ist.

pointercrash**

Tim schrieb:

Beispielweise
unqualified: int
qualified: const int, wobei const der type qualifier ist.

Andere qualifier wären dann static, volatile, aber nicht (un)signed, denn das ist ein ... ?

Was ist das dann für ein Satz, "darf mit Qualifier versehen sein oder auch nicht"? Eine Nullmeldung, würfelt's halt drum, Hauptsache da stehen viele Worte. Was schließt dieses Sätzlein eigentlich aus? Das double- Bitfield?

Implementation- defined meint dann doch den Compiler? Oder die Applikation? Also wenn der Compiler den Typ "Wurstbrot" kennt, kann ich ein Wurstbrot- Bitfield anlegen?
Oder ist es so gemeint, daß ich, falls ich per typedef eine struct Wurstbrot anlege, eine struct Wurstbrote mit Bitfields of struct Wurstbrot anlegen kann?

Das würde mich ziemlich erschüttern , denn ich kenne dieses Konstrukt bisher nur als Reservat für zarte Bit- Pflänzchen.

pointercrash() schrieb:

Tim schrieb:

Beispielweise
unqualified: int
qualified: const int, wobei const der type qualifier ist.

Andere qualifier wären dann static, volatile, aber nicht (un)signed, denn das ist ein ... ?

static ist kein qualifier, sondern ein storage-class-specifier. unsigned ist ein type-specifier.

pointercrash() schrieb:

Was ist das dann für ein Satz, "darf mit Qualifier versehen sein oder auch nicht"? Eine Nullmeldung, würfelt's halt drum, Hauptsache da stehen viele Worte. Was schließt dieses Sätzlein eigentlich aus? Das double- Bitfield?

Dieses Sätzchen schliesst imho erstmal gar nichts aus (dein double-Bitfield dürfte duch andere Paragraphen verhindert werden), es sagt vielmehr, dass es mit _Bool, signed int und unsigned int gehen muss.

pointercrash() schrieb:

Implementation- defined meint dann doch den Compiler?

Eher die Plattform (Compiler, OS, HW, etc.).

pointercrash() schrieb:

Oder ist es so gemeint, daß ich, falls ich per typedef eine struct Wurstbrot anlege, eine struct Wurstbrote mit Bitfields of struct Wurstbrot anlegen kann?

Es ist wohl eher so gemeint, dass eine Implementierung auch long long bitfields erlauben kann, aber eben nicht muss. Andere Konstrukte (wie dein double oben) dürften sonstwo abgehandelt werden.

pointercrash() schrieb:

Implementation- defined meint dann doch den Compiler?

compiler, linker und libraries. alles was nötig ist, um ein c-programm in einem ausführbaren haufen maschinencode zu verwandeln.