array of record; bzw. arrays in OOP

[Keldorn]

Hallo

Es geht mir noch mal um diese Array of record – Konstruktion von hier:

Delphi-Quellcode:

TTest4 = class(TObject) 
  private 
    Test: array of record 
                     i:integer; 
                     s:string; 
                     b:boolean; 
                   end;        
  protected

Für so ungewöhnlich halte ich das gar nicht. Klar kann man auch schreiben

Delphi-Quellcode:

  Type Tmyrecord = record 
    i:integer; 
    s:string; 
    b:boolean; 
  end;       
TTest4 = class(TObject)
  private 
    Test: array of Tmyrecord

Aber diesen Extra-Type braucht man nur für Übergaben in Proceduren etc., bei einer Direktzuweisung oder wenn dieser Type mehrfach verwendet werden soll. Wenn dieses nicht verwendet wird, braucht man diesen Extra-Type eigentlich gar nicht. Außerdem finde ich die Deklaration übersichtlicher, wenn alles in einer steht und ich mir nicht erst noch andere Typen anschauen muß.

Aber egal, jeder wie er möchte. Vielmehr interessiert mich:

Zitat von Sprint:

Viel schlimmer? Viel schlimmer ist, das du in einer objektorientierten Programmiersprache überhaupt Array's einsetzt.

Zitat von alcaeus:

Verboten nicht, aber verachtet….

Warum sind arrays verachtet, und wie sieht es da mit Records aus? Wenn ich Objekte in einer Liste verwalten will nehme ich eine Objectlist, für record ein array. Beides hat in seiner Art Vorteile. Wenn ich ein paar Variablen nur „gruppieren“ möchte, nehme ich ein record und erstell mir nicht erst eine neue Klasse, oder macht ihr aus einem Tpoint auch eine extra Klasse?
Auch interessiert mich, wenn arrays „verachtet“ sind, wie ihr mit einem völligen Verzicht auf Arrays programmieren wollt.

Mfg Frank

[sixarp]

Statt dem Record definierst du dir in OOP eine Klasse mit den Variablen des Records,
und instanzierst das ganze im jeden Array-Element oder verwendest
TList oder TObjectList statt dem Array.

[glaubnix]

Zitat von sixarp:

Statt dem Record definierst du dir in OOP eine Klasse mit den Variablen des Records,
und instanzierst das ganze im jeden Array-Element oder verwendest
TList oder TObjectList statt dem Array.

Und wieviel Speicher braucht das Ganze dann??? Kein Wunder, das man immer schellere Rechner braucht.

glaubnix

[maximov]

Zitat von glaubnix:

Zitat von sixarp:

Statt dem Record definierst du dir in OOP eine Klasse mit den Variablen des Records,
und instanzierst das ganze im jeden Array-Element oder verwendest
TList oder TObjectList statt dem Array.

Und wieviel Speicher braucht das Ganze dann??? Kein Wunder, das man immer schellere Rechner braucht.

glaubnix

8 byte pro eintrag! Das bisschen OOP overhead macht den kohl nicht fett und ja mitunter könnte das sinn machen eine klasse für einen vektor (TPoint) zu deklarieren, dann hätte man alle berechnungsmethoden wenigstens beisammen.

[Robert_G]

Zitat von sixarp:

Statt dem Record definierst du dir in OOP eine Klasse mit den Variablen des Records,
und instanzierst das ganze im jeden Array-Element oder verwendest
TList oder TObjectList statt dem Array.

Man nimmt ganz sicher keine TList, wenn es sich auch nur irgendwie vermweiden lässt.
TList beuntzt solchen *piep* als internen Array:
  TPointerList = array[0..MaxListSize - 1] of Pointer; Am praktischsten finde ich immer noch linked Lists, die man hinter einer Collection ""versteckt".

Arrays haben einen Vorteil gegenüber Listen: Random access.
Man kann sehr schnell auf Element[X] zu greifen. Mit einer linked List kann es dir im dümmsten Fall passieren, dass du sie von ganz vorne/hinten bis dort durchlaufen musst (außer man führt den letzten Zugriff als "Cache" mit )

Das war's auch schon mit den Vorteilen von Arrays. Mir fällt dazu einfach nix positives mehr ein.
Von Arrays kann man nicht ableiten. Arrays werden ständig kopiert, wenn sich ihre Größe ändert. eine Element in einem Arrays zu löschen ist verflucht hässlich.

Und was an Records sparsamer sein soll weiß wohl auch keiner. Die Dinger werden bei Zuweisung KOPIERT! Alles was (Size > 10-20Bytes) gehört einfach nicht in einen Record. (Ich persönlich packe gar nichts in solchen Krempel )
Bei Referenzen auf ein Objekt muss nur der Zeiger (4Bytes) kopiert werden.

Aber ich halte mich jetzt lieber zurück.

@maximov ich dachte Referenzen wären 4 Byte.

[maximov]

Zitat von Robert_G:

....
@maximov ich dachte Referenzen wären 4 Byte.

Ja, aber da hast du den VMT-pointer vergessen, den jedes objekt inne hat

[Keldorn]

Zitat von Robert_G:

TList beuntzt solchen *piep* als internen Array:
  TPointerList = array[0..MaxListSize - 1] of Pointer; Am praktischsten finde ich immer noch linked Lists, die man hinter einer Collection ""versteckt".

daher auch meine Frage. Man kommt aber immer wieder zu einer Tlist und einem array, egal was man benutzt. Hast du ein Bsp, wie du das mit der linked list meinst? Mir ist klar, wie eine solche Liste funktioniert, aber ich sehe die praktische Handhabung nicht so einfach.

[jbg]

Zitat von Robert_G:

Am praktischsten finde ich immer noch linked Lists, die man hinter einer Collection ""versteckt".

Meinst du etwa TCollection? Wenn ja: und was ist dann das: "FItems: TList;"

Zitat:

Arrays haben einen Vorteil gegenüber Listen: Random access.

Und noch einer: Man kann sich viel schneller durch sie durchiterieren, da man nur den Zeiger erhöhen muss und deswegen nur einen Speicherzugriff zum Auslesen der passenden Stelle braucht und nicht zwei, wie bei LinkedLists braucht (einen zum Auslesen von "Next" und einen zum Auslesen der Speicherstelle).

Zitat:

Das war's auch schon mit den Vorteilen von Arrays.

Für statische Dinge sind Arrays um Welten besser als LinkedLists. Für dynamische sieht das natürlich anders aus, wobei man sich hierbei zwischen schlechterer Zugriffsgeschwindigkeit und Herumkopiererei entscheiden muss.

Zitat:

Und was an Records sparsamer sein soll weiß wohl auch keiner.

Sie brauchen weniger Speicher als class, und genausoviel wie object ohne eine virtuelle Methode (object stammt ja von record ab).
Ein record kann auf dem Stack liegen, eine class liegt ohne Tricks immer im Heap.

Zitat:

Die Dinger werden bei Zuweisung KOPIERT! Bei Referenzen auf ein Objekt muss nur der Zeiger (4Bytes) kopiert werden.

Bei Referenzen auf einen Record muss auch nur der Zeiger (4Bytes) kopieren werden.
Da hast du wohl zwei unterschiedliche Sachen verglichen. Wenn man die Daten einer Klasse kopieren will muss man sich auch noch selbst darum kümmern (was seine Vorteile hat), oder man muss "Move(yourInstance^, myInstance^, myInstance.InstanceSize);" aufrufen, was einer Wert-Zuweisung im Sinne einer Records-KOPIE entspräche.

Zitat:

@maximov ich dachte Referenzen wären 4 Byte.

Zumindest unter 32Bit Prozessoren

[Robert_G]

Zitat von jbg:

Zitat von Robert_G:

Am praktischsten finde ich immer noch linked Lists, die man hinter einer Collection ""versteckt".

Meinst du etwa TCollection? Wenn ja: und was ist dann das: "FItems: TList;"

Ganz sicher meine ich das nicht.
Die dpCollection ist ganz nett um Einstellungen local zu speichern. Im Normallfall ist die Vorgabe von CollectionItem abzuleiten IMHO nicht zumutbar.
Ich meine eine Klasse, die intern eine linked list verwaltet. Ohne dass man sich im eigentlichen Code darum kümmern muss.
Abstraktes beispiel

Delphi-Quellcode:

var
  Instance :TMyClass;
begin
  MyClassCollection.Add(TMyClass.Create('eins'));
  MyClassCollection.Add(TMyClass.Create('zwei'));
  
  for Instance in MyClassCollection do
    WriteLn(Instance.SomeProperty);

  MyClassCollection.Clear();