Record helper für statische Arrays

[Dennis07]

Hallo Leute,
ich wollt mal fragen ob euch ein triftiger Grund einfällt, wieso ich für statische Arrays keine Helperklassen definieren kann.
Das geht ja sowohl bei dynamischen Arrays als auch bei Records und sogar bei kurzen Strings!
Mir fällt beim besten Willen kein Grund ein, warum das nicht auch bei statischen Arrays demnach gehen sollte.
Ist es einfach nur ein Compiler-Bug, oder spricht da eures Wissens nach irgendetwas gegen?

Danke!

[freimatz]

Der Grund dass es nicht geht liegt wohl daran, dass es nicht implementiert ist und das vielleicht weil bislang keiner einen Grund fand das zu wollen. Wozu brauchst du das denn?

[himitsu]

Klar, im Prinzip gäbe es keinen Grund, warum der Record-Helper nicht an einen statischen Array-Typen dran geht.
Ein statisches Array ist Verwaltungstechnisch nichts anderes, wie ein Record,
und für native Typen oder dynamische Arrays funktioniert der Record-Helper jedenfalls auch.

Delphi-Quellcode:

type
  TTest1 = Byte;
  TTest2 = array[0..10] of Byte;
  TTest3 = record x: array[0..10] of Byte end;
  TTest4 = record x: TTest2 end;

  TTest1Helper = record helper for TTest1 end;  // RecordHelper für nativen Typen geht
  TTest2Helper = record helper for TTest2 end;  // [dcc32 Fehler] E2474 Record-Typ erforderlich
  TTest3Helper = record helper for TTest3 end;  // RecordHelper an Record geht natürlich
  TTest4Helper = record helper for TTest4 end;  // und hier ebenfalls

Notfalls kann der Compiler hier auch einfach implizit einen Records drumrum legen.

Über einen Cast in den Record verschieben, oder direkt als Array-Record deklarieren.

Delphi-Quellcode:

type
  TTest = array[0..10] of Byte;
  TTestX = record x: TTest end;

  TTestHelper = record helper for TTestX
    procedure DoWhatever;
  end;

procedure TForm1.FormCreate(Sender: TObject);
var
  x: TTest;
begin
  TTestX(x).DoWhatever;
end;

Aber dann braucht man den Helper nicht unbedingt und kann es auch direkt in den Record reintun.

Delphi-Quellcode:

type
  TTest = array[0..10] of Byte;
  TTestX = record
    X: TTest
    procedure DoWhatever;
  end;

procedure TForm1.FormCreate(Sender: TObject);
var
  x: TTest;
begin
  TTestX(x).DoWhatever;
end;

Nun nochmal mit implizitem Cast versucht, aber Delphi möchte nicht die möglichen Casts durchprobieren.

Delphi-Quellcode:

type
  TTest = array[0..10] of Byte;
  TTestI = record
    X: TTest;
    class operator Implicit(Source: TTest): TTestI;
    procedure DoWhatever;
  end;

class operator TTestI.Implicit(Source: TTest): TTestI;
begin
  Result.X := Source;
end;

procedure TForm1.FormCreate(Sender: TObject);
var
  X: TTest;
begin
  X.DoWhatever;  // [dcc32 Fehler] E2018 Record, Objekt oder Klassentyp erforderlich
end;

Ein Array-Helper wäre was, für statische Arrays. (und auch für dynamische Arrays, notfalls ohne die Möglichkeit der Längenänderung, also behandelt wie statisch)

Delphi-Quellcode:

type
  TTest = array[0..10] of Byte;

  TTestHelper = array helper for Byte  
    procedure DoWhatever;
  end;

Für dynamische Arrays geht es ja.

Delphi-Quellcode:

type
  TTest = TArray<Byte>;

  TTestHelper = record helper for Test
    procedure DoWhatever;
  end;

  TTestHelper2 = record helper for TArray<Byte>  // das geht zwar auch, aber die Klassenvervollständigung wunderschön ab
    procedure DoWhatever;                        // Messagebox: END erwartet, aber '<' gefunden in Klasse TTestHelper2.
  end;

[Dennis07]

Zunächst einmal danke für die Antworten.

Zitat:

Zitat von freimatz (Beitrag 1458979)

Der Grund dass es nicht geht liegt wohl daran, dass es nicht implementiert ist und das vielleicht weil bislang keiner einen Grund fand das zu wollen.

Naja, wieso braucht man denn einen Grund, bei statischen Arrays keine Ausnahme zu machen? Wenn man ein Feature implementiert, dann sollte es schon einen expliziten Grund geben, weswegen man es für einen bestimmten Use-Case nicht zur Verfügung stellt. Zumal der Mehraufwand hier wohl wirklich minimal gewesen wäre

Zitat:

Zitat von freimatz (Beitrag 1458979)

Wozu brauchst du das denn?

Naja, wozu mal Helper nunmal "braucht". Als Erweiterung für Typen, die man nicht ableiten will oder kann. Aus dem selben Grund, wieso es auch Helper für Strings, Integers, Chars, GUIDs, etc... gibt. Es macht Code nunmal erheblich schöner und übersichtlicher, wenn man anstelle globaler Prozeduren und Funktionen Record-bzw. Class-Helper deklariert.

Zitat:

Zitat von himitsu (Beitrag 1458982)

...

Jo, das wäre natürlich eine Möglichkeit. Nur leider Gottes kann man mit Records nicht das selbe machen, das man mit statischen Arrays machen kann. Hier liegt nämlich das Problem: Bräuchte ich nicht genau statische Arrays, würde ich sie ja auch hier nicht benutzen. Aber in sehr vielen Situationen verlangt der Compiler nun einmal einen nicht-initialisierten/-finalisierten Typen, und da kann man nunmal keine Records oder dynamischen Arrays nehmen. Nur einfache Typen, Zeiger oder Statische Arrays.
Trotzdem Danke für den gut formulierten Hinweis. ;-)

[freimatz]

"Zumal der Mehraufwand hier wohl wirklich minimal gewesen wäre" - das sagen meine Kunden auch immer :wink:
Ich kann mir vorstellen dass es doch etwas mehr Aufwand ist. Ein record hat per see schon mehrere unterschiedliche Elemente, da noch etwas hinzufügen ist einfacher als bei etwas, das nur aus lauter gleichen Elementen besteht. Aber das ist nur eine Vermutung, ich kenne die Internas nicht.

"Naja, wozu mal Helper nunmal "braucht". Als Erweiterung für Typen, die man nicht ableiten will oder kann." - zu kann fallen mir alle Typen aus der RTL, VCL u.a. ein. Statische arrays sind mit da noch nicht untergekommen.
Selber haben wir öffentliche statische arrays nur bei Vektoren und Matrizen. Das gilt bei uns auch schon veraltet, man sollte den Record nehmen der das kapselt. So hat das ja auch himitsu vorgeschlagen.
In anderen Fällen würde ich eh immer eine Klasse drum rum bauen.

[himitsu]

Zitat:

Zitat von Dennis07 (Beitrag 1458986)

Nur einfache Typen, Zeiger oder Statische Arrays.

Das triff aber auch auf Records zu.

Wobei es so bei statischen Arrays und Records davon abhängt, was für Typen drin sind.
Strings und Interfaces und schon werden dieses Records/Arrays auch initialisiert und finalisiert (bzw. sie müssen es, sonst Preng und/oder Speicherlecks)

@freimats: Delphi verwaltet Records wie ein Array mit der Länge 1 (entsprechend

Delphi-Quellcode:

array of record

bzw.

Delphi-Quellcode:

array[...] of record

),
was man in der System.pas gern seinen Augen antun kann.

[Dennis07]

Zitat:

Zitat von freimatz (Beitrag 1458990)

Ein record hat per see schon mehrere unterschiedliche Elemente, da noch etwas hinzufügen ist einfacher als bei etwas, das nur aus lauter gleichen Elementen besteht. Aber das ist nur eine Vermutung, ich kenne die Internas nicht.

Naja, aber erstens haben Strings, Zahlen und dynamische Arrays auch keine Member, und zweitens sind das ja keine "echten" Member, sondern nur globale Routinen mit einem entsprechenden Parameter als "Self". RTTI und vererbung gibt es bei Helpern ja gar nicht. Insofern bezweifle ich durchaus, dass es tatsächlich noch mal deutlich mehr Arbeit gewesen wäre, das zu implementieren. Mir erscheint es eher wie eine willkürliche Einschränkung zu sein, als einen echten technischen Hintergrund zu haben.

Zitat:

Zitat von freimatz (Beitrag 1458990)

zu kann fallen mir alle Typen aus der RTL, VCL u.a. ein. Statische arrays sind mit da noch nicht untergekommen.
Selber haben wir öffentliche statische arrays nur bei Vektoren und Matrizen. Das gilt bei uns auch schon veraltet, man sollte den Record nehmen der das kapselt. So hat das ja auch himitsu vorgeschlagen.
In anderen Fällen würde ich eh immer eine Klasse drum rum bauen.

Joa, könnt ihr ja machen wie ihr wollt. Aber manchmal nimmt man halt Arrays, weil Records halt auch ihre Nachteile haben. Besonders wenn es darum geht, dass Record-Felder ja als Eigenschaften und Parameter ja Readonly sind.

Zitat:

Zitat von himitsu (Beitrag 1458991)

Wobei es so bei statischen Arrays und Records davon abhängt, was für Typen drin sind.
Strings und Interfaces und schon werden dieses Records/Arrays auch initialisiert und finalisiert (bzw. sie müssen es, sonst Preng und/oder Speicherlecks)

Joa eben, deshalb bringt es ja nichts... :-D

[himitsu]

Vererbung gibt es bei Helpern.

Zum Glück, denn sonst wären Helper zu nichts zu gebrauchen, wenn man selber Typen erweitern will und dann mit den vordefinierten Helpern kollidiert.
Ich hoffe aber noch, dass der Entwickler irgendwann mal den gravierenden Bug behebt, wonach immer nur der letzte Helper nutzbar ist, denn Helper aus Fremdkomponenten können nicht voneinander erben, vor allem nicht firemübergreifend.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1459017)

Vererbung gibt es bei Helpern.

Nur bei class helper for, nicht bei record helper for.

[himitsu]

Na das ist dann ja richtig doof.