Erklärung von record (Delphihilfe unverständlich :))

[ErdNussLocke]

Hi,

kann mir wer erklären, wie man die Funktion record benutzt?
Die Delphihilfe wirft wie immer nur noch mehr Rätsel auf.

Ich habe bisher verstanden, das man es unter type deklariert und mehrere Variablen verschiedenen Typs reinspeichern kann.
Nun versucht die Delphihilfe etwas mit "case" zu erkären, wo ich allerdings nicht durchsteige.
Bitte um Hilfe^^ (und um Fehlerberichtigung falls ich schon falsch liege)
Danke im Vorraus
MfG
ErdNussLocke

[mkinzler]

Ein Record ist einfach ein zusammengesetzter Datentyp.

z.B.

Delphi-Quellcode:

TAdresse = Record
    Name: string;
    Vorname: string;
    GebDat: TDate;
    ...
end;
...
adr: TAdresse;
...
   adr.Name := 'Erdnusslocke';
   adr.Vorname := '...'; 
    ...

[ErdNussLocke]

ok das is schonmal gut. danke dafür

und was hat es mit diesem case auf sich?

[mkinzler]

Was steht da genau mit dem case drinn?

[ErdNussLocke]

z.b. das hier

Delphi-Quellcode:

 TPolygon = record
   X, Y: Real;
   case Kind: Figure of
     TRectangle: (Height, Width: Real);
     TTriangle: (Side1, Side2, Angle: Real);
     TCircle: (Radius: Real);

[3_of_8]

Das ist schon ein recht fortschrittliches Sprachfeature.

Das erlaubt dir, deine records dynamisch zu deklarieren, das heißt die genauen Bestandteile des records hängen von dem Aufzählungswert Kind ab.

[mkinzler]

dabei handelt es sich nicht um einen normalen Record, sondern um einen Union. Je nach Wert einer Variable (hier Kind) sind andere Teile der Datenstruktur sichtbar.

[ErdNussLocke]

aso ok. warum schreiben die das nicht so in die Hilfe ;)

Vielen Dank an alle!

[alzaimar]

Zitat:

Zitat von 3_of_8

Das ist schon ein recht fortschrittliches Sprachfeature.

Nicht ganz. Es ist so alt wie Pascal selbst. Und damit bald 40 Jahre ...

Zitat:

Zitat von mkinzler

dabei handelt es sich nicht um einen normalen Record, sondern um einen Union. Je nach Wert einer Variable (hier Kind) sind andere Teile der Datenstruktur sichtbar.

Hmmjein. 'Union' heißen die Dinger in C, bei Pascal sind das 'variant records'. Kommt aber aufs gleiche raus :zwinker:

[Hansa]

Empfehlung von mir : Finger weg von dem Kram. Zumindest solange, wie Du denkst ein Record sei eine Funktion. :zwinker:

Zitat:

Zitat von mkinzler

sondern um einen Union

Da hat er sich vertan. Das ist ein Variant-Typ. Es gibt vielleicht einige Ausnahmefälle, wo der gebraucht wird. Im Normalfall aber nicht. Hatte auch mal getestet, was das überhaupt soll und danach nie mehr gebraucht.

[Edit] mir fällt gerade noch ein : der Variant braucht pro Einheit immer soviel Platz, wie das größte Element. Krasses Beispiel : der Variant besteht nur aus einem integer oder alternativ einem TImage von 5 MB. Der integer würde dann 5 MB belegen !! :cyclops:

[mkinzler]

Zitat:

Da hat er sich vertan. Das ist ein Variant-Typ.

Wie alzaimar geschrieben hat, ist das das Selbe in einer anderen Sprache ( Union = varianter record; Struktur = Record, ...)

[Hansa]

Die Frage steht aber bei Delphi-language und da ist das ein Variant. Guckt mal lieber noch nach meinem Edit oben, ob das unter Delphi wirklich noch so ist. :???:

[mkinzler]

Das mit dem Speicherverbrauch ist m.w. bei c genauso.

[Muetze1]

Zitat:

Zitat von Hansa

[Edit] mir fällt gerade noch ein : der Variant braucht pro Einheit immer soviel Platz, wie das größte Element. Krasses Beispiel : der Variant besteht nur aus einem integer oder alternativ einem TImage von 5 MB. Der integer würde dann 5 MB belegen !! :cyclops:

TImage? Wäre eine Klasse, somit würde es eine Instanzenvariable sein und das wäre wiederrum ein Pointer (intern) und somit auch 4 Byte gross...

w.z.b.w. *g*

[3_of_8]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von 3_of_8

Das ist schon ein recht fortschrittliches Sprachfeature.

Nicht ganz. Es ist so alt wie Pascal selbst. Und damit bald 40 Jahre ...

Ich meinte nicht "fortschrittlich" sondern "fortgeschritten". Gehört jedenfalls nicht ganz zu den Grundlagen von Delphi, IMHO.

[Hansa]

Zitat:

Zitat von 3_of_8

sondern "fortgeschritten". Gehört jedenfalls nicht ganz zu den Grundlagen von Delphi, IMHO.

Doch, doch. Das gehört schon zu den Delphi Ursprüngen. Alzaimar hat das doch gesagt. Genauer gesagt stammt das aus 1972 von der Ur-Pascal Definition von Nikolaus Wirth. Was ist nun daran fortgeschritten ? :zwinker: Im Zusammenhang mit Records, wohl gemerkt. Es geht nicht um den Datentyp Variant ! Es geht um eine alte Spielart von Records. Die nennt man Varianten, aber das Wort taucht in der Deklaration dieser Records im SOurce gar nicht auf. Die Delphi-Hilfe könnte das aber schon liefern.

@Muetze1 : Du behauptest also ernsthaft, ein beliebiges TImage würde nur 4 Byte brauchen ? :shock: Erkläre mal, was 10 TImages in verketteter Liste brauchen, wobei jedes 1 MB hat und die sollen abgespeichert werden. Das mußt Du mir mal vormachen mit 40 Bytes für 10 TImages. :mrgreen:

[mkinzler]

Zitat:

@Muetze1 : Du behauptest also ernsthaft, ein beliebiges TImage würde nur 4 Byte brauchen ? Shocked Erkläre mal, was 10 TImages in verketteter Liste brauchen, wobei jedes 1 MB hat und die sollen abgespeichert werden. Das mußt Du mir mal vormachen mit 40 Bytes für 10 TImages. Mr. Green

Das Image selber belegt natürlich mehr Speicher, die Referenz im (varianten) Record aber nur 4 Bytes.

[Cöster]

Was bedeutet eigentlich

Delphi-Quellcode:

case Integer of

wie es zum Beispiel in der Deklaration von TRect steht?

[3_of_8]

Dass es nicht von einem Ordinaltyp im Record, sondern von der Art des Aufrufs abhängig ist.

Beispiel:

Delphi-Quellcode:

type
  TARGB=record
  case Integer of
  0: (Value: Integer);
  1: (A, R, G, B: Byte);
  end;

//...

myARGB.Value:=$000000FF;
//...ist das gleiche wie...
myARGB.R:=255;

Achja: Mit "Keine Grundlage" meinte ich, dass man es als Anfänger nicht unbedingt wissen muss, sondern dass es eher etwas für Fortgeschrittene ist.

[Cöster]

Aha. Hat das einen Grund, warum es

Delphi-Quellcode:

case Integer of 
  0: { ... } 
  1: { ... }

heißt und nicht

Delphi-Quellcode:

case Boolean of
  True : { ... }
  False: { ... }

oder vielleicht auch Byte heißt, oder ist das einfach nur Zufall?

[3_of_8]

Ich denke mal das ist recht egal.

[Hansa]

Guck doch mal endlich in die Delphi-Hilfe. :roll: Hinter Case steht immer das, was später anhand seines Wertes ausgewertet werden muß. Im Case-Abschnitt für einen integer hat deshalb ein boolean-Wert nichts zu suchen und umgekehrt. Und bevor die nächste unvermeidliche Frage kommt : Ja, Strings, reals usw. gehen im Case nicht.

[3_of_8]

Delphi-Quellcode:

case Boolean of
  True : { ... }
  False: { ... }

Das müsste aber eigentlich gehen, wobei es aber irgendwie seltsam aussieht.

[Hansa]

Zitat:

Zitat von Hansa

Hinter Case steht immer das..

z.B. boolean

Zitat:

Zitat von Hansa

..was später anhand seines Wertes ausgewertet werden muß..

und zwar dann true oder false.

[3_of_8]

Zitat:

Im Case-Abschnitt für einen integer hat deshalb ein boolean-Wert nichts zu suchen und umgekehrt.

Das klang so, als hättest du seine Frage verneint. ;)

[Cöster]

Zitat:

Zitat von Hansa

Guck doch mal endlich in die Delphi-Hilfe. :roll:

Ist schon längst passiert. Da wird aber nur die Syntax

Delphi-Quellcode:

case <Name>:<Ordinal-Typbezeichner> of

genauer erklärt. Damit hatte ich auch nie Probleme, <Name> ist dann auch eine Eigenschaft des records. Aber Integer ist ja keine Eigenschaft von TRect. Was ist dieser Integer, wo wird ihm etwas zugewiesen, könnte man statt

Delphi-Quellcode:

0: { ... }
1: { ... }

auch

Delphi-Quellcode:

14: { ... }
15: { ... }

schreiben? Auslesen kann man anscheinend auch nicht, ob Integer 0 oder 1 ist, denn:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  R: TRect;
begin
  R := Rect(50, 50, 20, 20);
  Caption := IntToStr(R.TopLeft.y);
end;

Delphi weiß, dass z.B. R.TopLeft.y = R.Top ist? Woher?

[3_of_8]

Weil es der gleiche Speicherbereich ist... :roll:

[Cöster]

Zitat:

Zitat von 3_of_8

Weil es der gleiche Speicherbereich ist... :roll:

Ahso, das hängt also von der Reihenfolge der Deklaration ab. Danke

Hab das andere auch mal ausprobiert: Mit Boolean und anderen Typen geht das auch.

[Jasocul]

Natürlich geht ds mit allen ordinalen Typen. Genau, wie beim "richtigen" Case.
Steht im Record

Delphi-Quellcode:

case MeineVariable : Integer of

kann man vorher tatsächlich feststellen, welcher Wert vorliegt. Steht dort nur

Delphi-Quellcode:

case Integer of

, dann geht es nicht.
Was dann im Case-Block für Fälle drin stehen, ist im Grunde völlig egal. Man muss für die Varianten nur einen Datentyp nehmen, der genügend Varianten verwalten kann. Nimmt man Boolean, gehen nur zwei Varianten.

Beim Beispiel von TRect hätte Borland theoretisch auch ein Boolean statt Integer nehmen können, das es nur zwei Varianten gibt.

[mr-unbekannt]

hallo!

da ich noch kein "fortgeschrittener" bin, wollte ich mal die frage stellen, ob die records dann so etwas ähnliches wie eine klasse ist?

es schaut jedenfalls fast gleich aus

danke für die verbesserungen ;-)

mr

[mkinzler]

Zitat:

da ich noch kein "fortgeschrittener" bin, wollte ich mal die frage stellen, ob die records dann so etwas ähnliches wie eine klasse ist?

Nein. Da sie keine Methoden besitzen. Records werden auch heterogene Bereichsvariablen oder Strukturen bezeichnet.

[alzaimar]

Spätestens seit BDS 2006 kann man in Records auch Methoden verwenden.

Zitat:

Zitat von 3_of_8

Beispiel:

Delphi-Quellcode:

type
  TARGB=record
  case Integer of
  0: (Value: Integer);
  1: (A, R, G, B: Byte);
  end;

//...
myARGB.Value:=$000000FF;
//...ist das gleiche wie...
myARGB.R:=255;

Nee. Nicht ganz (aber das weisst Du selber). Die Zeile

Delphi-Quellcode:

myARGB.Value:=$000000FF;

verändert alle vier Bytes (A=255 und R,G,B = 0), während

Delphi-Quellcode:

myARGB.R:=255;

Nur das eine Byte (Das zweite von rechts :mrgreen:) verändert.

Ein 'Record' ist imho ein Überbleibsel aus den Anfängen der strukturierten Programmierung. Um alle Bits eines Bytes (in Standardpascal) anzusprechen, blieb nur dieses Konstrukt (AND/OR auf Byte-Ebene ging nicht, einer der Gründe warum es dann mal 'Turbopascal 1.0' gab):

Delphi-Quellcode:

Type
  TNibble = 0..15;
  TBitsNibblesAndByte = Packed Record
    Case Integer Of
     0 :  (TheByte : 0..255);
     1 : (TheNibbles : Array [0..1] Of TNibble);
     2 : (The Bits : Array [0..7] Of Boolean);
  End;

Das 'packed' veranlasst(e) den Compiler, das Record so dicht wie möglich zu packen. Da ein Boolean genau ein Bit benötigt, ein Nibble (0..15) genau 5 bits, kann man so bei einem Byte sowohl auf die Nibbles (halbe Bytes) als auch auf die einzelnen Bits zugreifen. Leider klappt das mit dem Packed heute nicht mehr.

Bei der Programmierung von Treibern (ja ja, ging früher, unter Win32 nicht mehr so leicht) sind häufig die Statusinformationen in den einzelnen Bits eines Statusbytes/Wortes kodiert. Durch die Deklaration eines geeigneten 'Packed Records' konnte man dann sehr elegant auf die einzelnen Informationen zugreifen. Heute verwendet man Masken und AND bzw. OR

Soweit ich weiss (bin aber C-Laie), dürfte das heute in C auch noch gehen, das weiss ich aber nicht.

[3_of_8]

@mkinzler: Wenn ich mich nicht irre, können records seit D2006 auch Methoden besitzen.

Man könnte records entfernt mit Klassen vergleichen, jedoch müssen Klassen instantiiert und freigegeben werden, das heißt der Programmierer muss sich darum kümmern, dass der Konstruktor vor dem ersten Zugriff aufgerufen wurde und dass die Klasse auch wieder freigegeben wird.

Records hingegen werden von Delphi selbst verwaltet, auf die kann man also immer sofort zugreifen.

Records können auch sehr leicht abgespeichert oder in Strömen verschickt werden.

Sie können Methoden besitzen (ab D2006), aber verfügen IMHO nicht über Vererbung, Kapselung und das ganze Zeug drumherum.

[mkinzler]

Zitat:

@mkinzler: Wenn ich mich nicht irre, können records seit D2006 auch Methoden besitzen.

Du meinst class operators, daß sind aber imho keine richtigen Methoden und machen aus einem Record keine Klasse.

[Khabarakh]

@3von8: Schön, den wichtigsten Unterschied hast du vergessen ;) .
Records sind Wertetypen, Klassen Referenztypen. Das ist der einzige Grund, warum Records noch nicht veraltet sind. In den übrigen Unterschieden gleichen sich beide Typen langsam aneinander an - natürlich beide in Richtung OOP: Records/Structs/... bekommen Methoden, Properties, Events und Konstruktoren, sogar ein wenig Vererbung durch Interfaces, Klassen werden genauso einfach verwaltbar wie Records.

@mkinzler: Nein, meint er nicht ;) .

[Cöster]

Zitat:

Zitat von Die Delphi-Hilfe

Zusätzlich zu den traditionellen Record-Typen lässt die Delphi-Sprache komplexere und “klassenähnliche” Record-Typen zu. Zu den Feldern können Records Eigenschaften und Methoden (einschließlich Konstruktoren), Klasseneigenschaften, Klassenmethoden, Klassenfelder und verschachtelte Typen haben. Weitere Informationen hierzu finden Sie in der Dokumentation zu Klassen und Objekten. Im Folgenden finden Sie eine Beispiel-Record-Typdefinition mit einigen “klassenähnlichen” Merkmalen.

Delphi-Quellcode:

type
  TMyRecord = record
    type
      TInnerColorType = Integer;
    var
      Red: Integer;
    class var
      Blue: Integer;
    procedure printRed();
    constructor Create(val: Integer);
    property RedProperty: TInnerColorType read Red write Red;
    class property BlueProp: TInnerColorType read Blue write Blue;
end;

constructor TMyRecord.Create(val: Integer);
begin
  Red := val;
end;

procedure TMyRecord.printRed;
begin
  writeln('Red: ', Red);
end;

Obwohl Records nun einige der Merkmale von Klassen besitzen, gibt es wichtige Unterschiede zwischen Klassen und Records.

• Records unterstützen keine Vererbung.
• Records können variante Teile enthalten; Klassen nicht.
• Records sind Wertetypen, daher werden Sie bei der Zuweisung kopiert, per Wert übergeben und dem Stack zugewiesen, wenn sie nicht als global definiert sind oder explizit mit den Funktionen New und Dispose zugewiesen werden. Klassen sind Referenztypen, daher werden Sie bei der Zuweisung nicht kopiert, per Referenz übergeben und dem Heap zugewiesen.
• Records ermöglichen das Überladen von Operatoren auf Win32- und .NET-Plattformen; Klassen ermöglichen das Überladen von Operatoren nur bei .NET.
• Records werden automatisch mit einem Standardkonstruktor ohne Argumente erzeugt, Klassen dagegen müssen explizit erzeugt werden. Weil Records einen argumentlosen Standardkonstruktor haben, muss jeder benutzerdefinierte Record-Konstruktor ein oder mehr Parameter haben.
• Record-Typen können keine Destruktoren haben.
• Virtuelle Methoden (die mit den Schlüsselwörtern virtual, dynamic und message angegeben werden) dürfen in Record-Typen nicht verwendet werden.
• Im Gegensatz zu Klassen können Record-Typen auf der Win32-Plattform keine Schnittstellen implementieren; auf der .NET-Plattform können Records jedoch Schnittstellen implementieren.