Datentyp mit 3 Bytes

columbus

Hallo zusammen,
für eine Projektaufgabe habe ich die Aufgabe einen Datentyp zu definieren, welcher aus drei Byte besteht. Ich habe jetzt erst mal vor eine Struct zu definieren, die aus drei unsigned char besteht. Aber gibt es da nicht noch was besseres? Mit Bitfields oder so?

Vielen Dank vorab...

Gruss Christian

Badestrand

columbus schrieb:

Ich habe jetzt erst mal vor eine Struct zu definieren, die aus drei unsigned char besteht.

Würde ich auch so machen. Ob die 'char's unsigned sind, ist dabei egal, die sind jeweils ein Byte groß Bitfelder bringen dir hier nichts, die werden benötigt, um einfacher auf Teile von Bytes zugreifen zu können.

Für was genau wird dieser 3-Byte-Typ denn gebraucht? Wenn man sich sowas wie einen 24-Bit Integer bauen will, würde ich schon bitfields verwenden.

columbus

Es soll schon ein Datentyp sein, der sich wie Integer anfühlt, also Ganzzahlig, mit der Möglichkeit von 0 bis 16,7 Millionen zu zählen.

Von daher ist die Lösung mit den drei char-Feldern nicht so optimal. Ich muss dann den Zugriff auf dieses Feld selbst regeln. Denn wenn die ersten 255 voll sind soll die Anwendung das zweite Feld beschreiben usw. Das ist sicher nicht unmöglich aber umständlich. Und schön leider auch nicht.

Gruss Christian

Tachyon

typedef unsigned char three_byte_type[3];

Badestrand schrieb:

Bitfelder bringen dir hier nichts, die werden benötigt, um einfacher auf Teile von Bytes zugreifen zu können.

naja, um auf teile von bytes zuzugreifen würde ich lieber shifts und logikoperationen nehmen. bitfield sind gut zur kompression von krummen datentypen (z.b. 3,3,2 in einem byte) oder, so wie's der OP braucht, 24bits am stück. wobei ein 24-bit datentyp oft trotzdem 4 bytes speicher belegt, aber nur 3 verwendet werden.

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

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.