Bitfelder in Delphi möglich?

[Cyf]

Mal eine relativ kurze Frage, kennt Pascal/Delphi eine Möglichkeit Bitfelder, wie sie in C möglich sind zu definieren?
Mal ein kleines Beispiel:

Code:

struct Bitfeld{
  unsigned bit1:1;
  unsigned bit2:1;
  unsigned :6;
    }

Klar man kann das ganze auch anders handhaben und mittels and, or und xor sowas realisieren, aber die Frage ist was einfach er zu handhaben ist, wenn man zum Beispiel mehrere Boolwerte speichern muss.

[Apollonius]

Nein, Bitfelder gibt es nicht. Statt den Bitoperationen kannst du aber Mengen verwenden.

[Cyf]

Also ich hab mir das mal angesehen und intern scheint das ganze ja auch nichts anderes als ein Bitfeld zu sein, wird ja bei verschiedenen Aufrufen auch oft mit Konstanten verwendet, ich habs mal getestet:

Delphi-Quellcode:

var
  Form1: TForm1;
  aSet: set of 0..7;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  aSet := [0, 3];  // 0: 1, 1: 2, 2: 4, 3: 8, usw. , [0,3] = 9
  aSet := aSet + [8]; //kein Effekt weil außerhalb der Range, entspricht 2^8
  Showmessage(IntToStr(SizeOf(aSet))); //1
  Showmessage(IntToStr(PByte(@aSet)^)); //9
end;

Ändere ich nun das Set auf 1..8, so beträgt die Größe 2 Byte, 15..16 resultiert ebenfalls in 2 Byte, 16..23 wieder nur in eins.
Die Grenzen scheinen immer bei k * 8 (k Element N) zu liegen. Warum geht Delphi da so vor und verwendet nicht immer einfach die Anzahl benötigter Werte (sprich die Bits jedes angefangenen Bytes)?
Wobei das schon mal eine sehr gute Hilfe war, Danke.

[Bernhard Geyer]

Zitat:

Zitat von Cyf

Warum geht Delphi da so vor und verwendet nicht immer einfach die Anzahl benötigter Werte (sprich die Bits jedes angefangenen Bytes)?

Und was machst du mit den letzten Bits? Die ersten Bits eines Strings reinpacken? Das würde nicht gerade schnelle Programme produzieren :-)

[Cyf]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Cyf

Warum geht Delphi da so vor und verwendet nicht immer einfach die Anzahl benötigter Werte (sprich die Bits jedes angefangenen Bytes)?

Und was machst du mit den letzten Bits? Die ersten Bits eines Strings reinpacken? Das würde nicht gerade schnelle Programme produzieren :-)

?

Ich meinte, dass ein

Delphi-Quellcode:

var Set: set of 1..8;
...
aSet:= [8]

zu der Bitverteilung

Code:

0 0 0 0 0 0 0 0  1 0 0 0 0 0 0 0

anstatt von

Code:

0 0 0 0 0 0 0 1

wird, was ja auch ausreichen würde, nicht das er alle restlichen Bits, die hintendran nicht verwendet werden, wegfallen lassen soll, das würde auch von der Adressierung her garnicht funktionieren. Die nötigen Bits lassen sich ja einfach durch (n2 - n1)+1 berechnen und müssten nur auf ein volles Byte ergänzt werden. Oder reden wir aneinander vorbei? :)

[Bernhard Geyer]

Zitat:

Zitat von Cyf

Oder reden wir aneinander vorbei? :)

Scheinbar (obwohl es heute nicht so warm ist) :-)

Ich denke es könnte auch mit Alignment zusammenhängen. 1 Byte Alignment ist bei modernen Prozessoren nicht gerade sehr performant zu realisieren. 2 Byte geht noch und 4 Byte is eigentlich ganz gut. Deshalb wird hier u.U. ein kompromiss zwischen Performance und RAM-Bedarf.

[toms]

Hallo, vielleicht ist der Artikel Working with bitfields in Delphi hilfreich.

[alzaimar]

Einen expliziten Zugriff auf Bits gab es früher durch die Verwendung eines Packed Record/Packed Arrays.

Delphi-Quellcode:

Type
  TMachineStatus = Packed Record
     Bits0And1 : 0..3;
     Bit2 : Boolean;
     Bits4..6 : 0..7;
     Bit7..15 : Array [7..15] Of Boolean;
  End;

ergab (korrekte Rechnung meinerseits vorausgesetzt) exakt 16 Bit = 2 Byte.

Wegen der von Bernhard angesprochenen Fokussierung auf Performance gibt es diese Dinge nicht mehr. Die OH schreibt dazu sinngemäß, das das 'packed' Schlüsselwort ignoriert wird.

Andererseits wird kaum noch hardwarenah programmiert (vor allen Dingen mit Pascal/Delphi nicht), und so ist die Motivation imho nicht gegeben, Datenstrukturen bitgenau und möglichst platzsparend abbilden zu müssen.

[Cyf]

Hmm... Ich denke nicht das es am Aligment liegt, sofern man nicht grad an den packed eigenschaften rumgespielt hat, würde er sonst normalerweise auch 4er Aligment verwenden.
Eventuell ist es schlichtweg einfacher (schneller) für Delphi, das ganze in 8er Schritten immer vom ersten Bit aus zu betrachten und dafür ein Byte zu opfern, als dafür extra Berechnungen anzustellen. Sprich er zieht so oft bei beiden Werten 8 ab wie er es kann ohne beim kleineren Wert ins Negative zu kommen und betrachtet dann die 2er Potenzen (vom Index 0 aus). Das Ganze ist ja auch primär dafür gedacht einfache ja/nein Eigenschaften zu speichern und nicht dafür, den Speicherplatz bis auf das letzte auszureizen oder über Netzwerk verschickt zu werden. Wenn der Programmierer weiß das er, sowas noch damit vor hat, kann er das ganze ja auch vorher entsprechend definieren. Zur Compilierzeit ist das Problem ja nicht zu lösen, falls man Sets auch mit variablen Längen definieren kann (was ich jetzt grad nciht probiert hab, aber ich meine sowas wie set of globalA..globalB). Und wenn man dabei, wenn sie von vornerein bekannt sind, anders damit umgehen würde, ist das ganze nicht mehr einheitlich.
Eigentlich ist das Ganze auch völlig egal, solange mans weiß, der Rest ist Sache von CodeGear. :wink:

[Cyf]

Ups sind dann doch 2 dazwischen gekommen.
Die Abschaffung von packed hat sichlerlich einige alte Codes inkompatibel gemacht.
Das Ganze könnte aber auch noch den Grund gehabt haben, das einige Systeme damit offensichtlicht nicht so gut klarkommen. Ich habe mal eine minimale C-Struktur versucht damit zu zwingen, was auf Vista 32-bit dazu führte das ein sizeOf() plötlich über 100 Kilobyte lieferte.
Naja, wie auch immer wie schon gesagt, ist es eigentlich ohnehin irrelevant.