Ein einfacherer Zugriff auf die Mitglieder eines UDTs ist durch den WITH-Block möglich. Zusammen mit WITH wird der Name des UDTs angegeben, auf dessen Elemente zugegriffen werden soll. Beim Zugriff auf ein Mitglied dieses UDTs kann anschließend innerhalb des Blocks der UDT-Name weggelassen werden. Das Mitglied beginnt dann mit einem Punkt.

WITH-Blöcke können ineinander verschachtelt sein. Es gilt dann immer das UDT des innersten Blocks, in dem sich das Programm zur Zeit befindet. END WITH beendet den aktuellen WITH-Block.

Die Speicherplätze für die Attribute eines UDTs liegen direkt hintereinander (ein weiterer Vorteil von UDTs, weil sie sich dadurch oft komplett an einem Stück speichern und laden lassen² ). Die Speicherstellen werden in der Regel „dicht aneinander“ gepackt, wobei jedoch „Füllstellen“ freigelassen werden können, wenn dadurch ein einfacherer Speicherzugriff möglich wird. Man spricht hier vom Padding.

Besteht ein UDT aus drei BYTE-Attributen, so benötigt es drei Byte Speicherplatz. Besteht es jedoch aus einem BYTE und einem INTEGER, dann wäre es unpraktisch, den INTEGER-Wert direkt hinter das BYTE zu hängen. Ein INTEGER hat ja den Vorteil, dass es direkt in einem Arbeitsschritt gelesen bzw. geschrieben werden kann. Das funktioniert aber nicht, wenn sein Speicherbereich über die Grenze einer INTEGER-Speicherstelle hinausragt. An dieser Stelle kommt das Padding ins Spiel: Der Speicherbereich wird automatisch so ausgeweitet, dass ein schneller Datenzugriff ermöglicht wird. Allerdings können Sie dieses Verhalten auch beeinflussen.

Das Padding-Verhalten soll in Quelltext 7.5 veranschaulicht werden. Wir nutzen dazu zwei Funktionen: Mit SIZEOF() lässt sich die Speichergröße eines Elements ausgeben. Man kann damit die Anzahl der Bytes ausgeben lassen, die von einer angegebenen Variablen, aber auch von Variablen eines angegebenen Datentyps belegt werden. Um das Offset, also die Speicherposition eines Attributs relativ zu seinem UDT zu ermitteln, dient OFFSETOF(). Das erste Attribut, das in einer UDT-Definition angegeben wird, hat immer das Offset 0.

Diese Ausgabe gilt für die 32-Bit-Version des Compilers. Wie die Speicherbelegung zustande kommt, lässt sich schematisch folgendermaßen darstellen:

Die grau gefärbten Bereiche geben den belegten Speicher an. Sobald ein größerer Datentyp verwendet wird, wie in diesem Beispiel ein (32-Bit-)Integer, findet ein Padding auf die Größe dieses Datentyps statt.³ Das wird vor allem beim UDT T3 deutlich: Auch der Platz hinter dem letzten einzelnen Byte wird auf vier Bytes aufgefüllt.

Das Standard-Paddingverhalten kann durch das Schlüsselwort FIELD verändert werden. Sie können das Padding dadurch allerdings nur verkleinern, nicht vergrößern.

T5 unterscheidet sich von T4 durch das größere Padding. T6 verwendet zwar dasselbe Padding wie T5, belegt aber trotzdem weniger Speicher, da die Attribute platzsparender angeordnet sind. Schematisch dargestellt sieht das so aus:

Durch eine geringere Ausdehnung wird Speicherplatz gespart, Sie sehen jedoch, dass das Integer nun nicht mehr eine vollständige Integer-Stelle belegt, sondern sich über eine der Grenzen erstreckt. Der Bonus bei der Zugriffgeschwindigkeit geht damit verloren. In der Regel wird FIELD nur verwendet, um eine Kompatibilität zu externen Bibliotheken herzustellen. Wenn dort die Speicherverwaltung anders abläuft als unter FreeBASIC, kommt es unweigerlich zu Problemen. Ansonsten lohnt sich der Einsatz von Padding in der Regel nicht — sinnvoller ist es, die Attribute so in der Deklaration anzuordnen, dass die durch das Padding entstehenden Lücken nicht unnötig groß werden.

Manchmal benötigt man deutlich kleinere Datentypen als ein BYTE. In einem Formular mit mehreren Kontrollkästchen werden eine Reihe von Variablen benötigt, die lediglich den Zustand „angeklickt“ oder „nicht angeklickt“ speichern müssen. Es reicht also jeweils ein Bit pro Kontrollkästchen.

So etwas lässt sich über Bitfelder lösen. Dazu wird eine Ganzzahl-Variable in eine Anzahl von einzelnen Bits aufgeteilt. Wir erinnern uns: Jedes Bit kann zwei Zustände annehmen (1 oder 0). Mit zwei Bits sind dann 2²=4 Zustände möglich, mit drei Bits 2³=8 usw. Eine solche Aufsplittung ist nur innerhalb eines UDTs erlaubt. Dazu wird hinter dem Attributnamen ein Doppelpunkt geschrieben, gefolgt von der gewünschten Bit-Zahl.

Hier werden drei Attribute deklariert, von denen zwei ein Bit lang sind und eines drei Bit lang. Das bedeutet: button1 und button2 können jeweils nur zwei verschiedene Werte annehmen (0 oder 1), radio dagegen acht (von 0 bis 7). Wenn Sie einem Attribut einen zu großen Wert zuweisen wollen, wird dieser automatisch „zurechtgestutzt“. Wenn Sie also z. B. in radio den Wert 10 speichern wollen (binär 1010), werden nur die hinteren drei Bit verwendet und der Rest verworfen — gespeichert wird damit der Wert 2. Abgesehen davon verhalten sich Bitfelder jedoch ganz genauso wie andere Attribute.

Es sollte noch ergänzt werden, dass die gewählte Bitzahl nicht größer sein kann als die Bitzahl des zugrunde liegenden Datentyps. Es können z. B. keine 9 Bit eines BYTE verwendet werden oder 33 Bit eines 32-Bit-Integers (sehr wohl aber eines 64-Bit-Integers). Außerdem wird LONGINT nur in der 64-Bit-Version des Compilers unterstützt.

Des Weiteren wird ein UDT immer vollständige Bytes als Speicherplatz belegen. Ein UDT mit einem einzigen Bitfeld-Attribut wird keine Speicherersparnis mit sich bringen. Selbst wenn das Attribut nur ein einziges Bit belegt, wird die Größe des UDTs durch die Größe des gewählten Datentyps festgelegt. Eine Platzersparnis tritt erst ein, wenn der Speicherplatz des gewählten Datentyps auf mehrere Attribute aufgeteilt wird.

Eine UNION ist ein UDT, dessen Elemente sich dieselbe Speicheradresse teilen. Abhängig vom Einsatzbereich kann der Inhalt der Speicherstelle auf verschiedene Arten interpretiert werden, eine Änderung des Inhalts wirkt sich aber natürlich auch auf die anderen Elemente aus.

wert.byteVar interpretiert den Speicherinhalt nur als BYTE, wodurch sich der ausgegebene Wert 4 ergibt. In diesem Fall hätte natürlich eine einfache Typumwandlung von SHORT zu BYTE ausgereicht. In den Zeilen 14 und 15 sieht man aber, dass eine Änderung von wert.byteVAR nur das erste Byte von wert.shortVar verändert und das andere Byte unverändert lässt.

Gern verwendet wird UNION innerhalb eines UDTs, das für mehrere Zwecke eingesetzt werden soll. Elemente, die nicht gleichzeitig zum Einsatz kommen, können sich eine Speicherstelle teilen, da sie sich ja nicht gegenseitig in die Quere kommen können. FreeBASIC selbst nutzt das bei der Deklaration von Grafik-Headern. Die alten QuickBASIC-Header sind folgendermaßen aufgebaut:

Für die Ansprüche von FreeBASIC ist eine Beschränkung auf 8191 Pixel Bildbreite nicht unbedingt wünschenswert. Deswegen wurde ein neues Header-Format gewählt, das zusätzlich noch Platz für weitere Informationen bietet. Da aber auch die im alten QuickBASIC-Format gespeicherten Bilder noch unterstützt werden sollen, wurde der neue Header folgendermaßen definiert:

type gibt die Versionsnummer des Headers zurück; beim neuen Headerformat ist das immer 7. Der alte Header kann dagegen niemals den Wert 7 annehmen. Abhängig von type kann FreeBASIC also entscheiden, ob die weiteren Daten nach dem alten oder neuen Header-Format interpretiert werden müssen.

Eine innerhalb von TYPE-Deklarationen verwendete UNION darf keinen eigenen Bezeichner erhalten. Stattdessen werden die UNION-Attribute direkt über den Bezeichner des UDTs angesprochen, also z. B. im oben stehenden Grafik-Header folgendermaßen:

Ein weiteres Beispiel direkt aus dem FreeBASIC-internen Fundus stellt das UDT Event dar, das von der Funktion SCREENEVENT() verwendet wird. Wir werden uns mit diesem Befehl in [KapGrafikScreenevent] genauer beschäftigen. Kurz gesagt geht es um die Abfrage bestimmter Ereignisse wie Mausbewegung, Tastendruck, Betreten oder Verlassen des Grafikfensters usw. Dabei liefern die verschiedenen Ereignisse teils unterschiedliche Informationen — z. B. ist es für die Mausbewegung wichtig, wohin die Maus bewegt wurde, während ein Tastendruck die gedrückte Taste zurückgeben soll. Da weder die Maus einen Tastendruck zurückgibt noch die Tastatur eine Mausposition, können sich beide Informationen den Speicherbereich teilen.

Die folgenden Programmieraufgaben bauen aufeinander auf. Sie können also mit dem Ergebnis aus Aufgabe 1 in Aufgabe 2 weiterarbeiten und mit diesem Ergebnis in Aufgabe 3.

Fußnoten:
¹⁾ In [KapOOP] werden wir lernen, dass es zwei Arten von Mitgliedern gibt: Die Attribute (Member-Variablen) und die Methoden (Member-Funktionen).

²⁾ Das funktioniert nur, wenn alle Attribute eine feste Länge besitzen, also u. a. keine Strings variabler Länge eingesetzt werden.

³⁾ Genauer gesagt wird das Standard-Padding durch den größten Datentyp festgelegt, beträgt aber höchstens 4 (unter 32-Bit x86 Linux/BSD) bzw. 8 (bei allen anderen Systemen).