Record helper für statische Arrays

[Dennis07]

Zunächst einmal danke für die Antworten.

Zitat von 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.

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 von freimatz:

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 von himitsu:

...

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
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.

[Dennis07]

Zitat von freimatz:

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 von freimatz:

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 von himitsu:

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...

[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 von himitsu:

Vererbung gibt es bei Helpern.

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

[himitsu]

Na das ist dann ja richtig doof.

[Dennis07]

Ich weiß im Augenblick nicht ganz, was ihr mit "Vererbung" hier meint. Denn Class Helper lassen sich ja nicht ableiten.

[Jost Riedel]

Wenn man allerdings das statische Array in einen record einhüllt, dann braucht keinen record helper mehr:

type
ByteArray10 = record
x: array[0..10] of Byte;
procedure DoWhatever;
end;

procedure ByteArray10.DoWhatever;
begin
end;

Es ist schon spaßig: Für records braucht man keine "record helper", einen helper für einen enumerierten Typ, ein Set, usw. "record helper" zu nennen ist schon etwas irreführend.

[himitsu]

Zitat von Dennis07:

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 array of record bzw. array[...] of record ),
was man in der System.pas gern seinen Augen antun kann.