statisch deklarierte records mit automatischen Constructor

[stoxx]

ob es sowas denn irgendwann geben wird in Delphi 2011 bitte?
dass ein automatischer Constructor Aufruf erfolgt, bevor ein statisch angelegter Record verwendet wird, also quasi bei der Speichergenerierung?

weiß jemand, ob sowas geplant ist?

also wie statische Klassen in C sozusagen?

[himitsu]

Jupp, sowas wünsche ich mir auch schon länger

Praktisch 2 neue Operatoren für InitializeRecord und FinalizeRecord.

ich hatte es nur das Initialize zu simulieren, indem ich einen String bzw. ein dynamisches Array dafür mißbrauchte, welcher dieses ja inne hat

Aber theoretisch könnte man sich das Finalize und ein verzögertest Initialize (praktisch beim Aufrufen einer Methode des Records) über einen Interface irgendwie zusammenbasteln

[Phoenix]

Naja.. comm... das Record.Create kannst Du ja wohl noch von Hand aufrufen?
Ich mein - konstruktoren für Records sind ja nix neues mehr. Der automatische Aufruf ist halt ned da... Aber wenn man das weiss kann man den ja auch selber aufrufen.

Ansonsten: Feature request in QC eintragen und beten

[himitsu]

praktisch ein "automatisches" Event, wie bei Interfaces, wäre nicht schlecht.

halt wie es bei den dynamischen Arrays und Strings auch de Fall ist.
(wenn Variable erstellt, kopiert und freigegeben wird)

[alzaimar]

Was ich mich wünsche, ist ein automatischer Problemsolver, der mir endlich meine Probleme löst, indem ich einfach das program Keyword eintippe. Ich schreib das mal an Embarcadero. So schwer kann das ja wohl nicht sein.

Mal im Ernst: Meint ihr nicht auch, das Code dann noch unleserlicher wird? Ich möchte in meinen Programmen weitestgehend steuern, ob und wann Code ausgeführt wird. Es kann doch nicht sein, das folgender Code meine Festplatte formatiert:

Delphi-Quellcode:

Programm HarmlosOderNicht;
Uses Harmlos;
Var
  X : TWirklichGanzHarmlosHarHar;

Begin
End.

Sowas meint ihr doch, oder?

[himitsu]

da X nicht genutzt wird, kürzt Delphi das raus und nix passiert
(und Notfalls hau ich das Formatieren in den Initialisations-Abschnitt 'ner Unit und fertig,
also automatischer Code ist nicht nur hier "gefährlich")

wieso denn nicht? derartig automatische Dinge (Compilermagic) kennen wir doch
schon zu Genüge (Paradebeispiele: Strings und dynamische Arrays),
also warum soll man sich dann sowas nicht auch für eigene Typen wünschen?


OK, Operatoren für Objekte/Interfaces wären noch geil

[stoxx]

Zitat von Phoenix:

Naja.. comm... das Record.Create kannst Du ja wohl noch von Hand aufrufen?

alle Sachen, die sich trotz grobem Fehler compilieren lassen, sind schlecht, weil die Softwarequalität darunter leidet.
Wenn ein Klassenpointer nicht createt ist, dann merkt man das sehr gleich. Das Programm mit einem uninitialisiertem Record läuft erstmal trotzdem.
Und das ist nicht gut.

[SirThornberry]

Zitat:

praktisch ein "automatisches" Event, wie bei Interfaces, wäre nicht schlecht.

Und warum verwendet man dann nicht einfach Interfaces?
Den Wunsch kann ich geringfügig verstehen aber man sollte Bedenken das es Bereits Objecte (die Constructoren unterstützen gibt). Und wenn man einen Constructor will soll man doch Objekte nehmen. Will man keinen kann man einen Record nehmen. Wenn wir jetzt noch den Record mit Constructoren versehen müsste ja etwas neues eingeführt werden damit es wieder etwas ohne constructoren gibt.
Ich fände dann sinnvoller das man bei der Declaration gleich Zuweisungen vornehmen kann (wie bei globalen Variablen bzw. wie in anderen Programmiersprachen)

[alzaimar]

Zitat von himitsu:

da X nicht genutzt wird, kürzt Delphi das raus und nix passiert

Glaub ich nicht, denn das wäre noch schlimmer. Und wann wird denn dann der Code ausgeführt? Wenn ich eine Unit nicht weiter verwende, wird der 'Initialization'-Teil doch auch ausgeführt. Also wird das nicht rausgekürzt. Oder doch? Super übersichtlich. Ist noch nicht mal implementiert und schon weis man nicht, was passiert.

Zitat von himitsu:

also automatischer Code ist nicht nur hier "gefährlich")... (Compilermagic) kennen wir doch
schon zu Genüge (Paradebeispiele: Strings und dynamische Arrays)

Mann muss doch nicht dafür sorgen, das noch mehr Compilermagic dazu kommt. Dann kann man doch gleich Visual Basic nehmen.

Ich mag Delphi gerade wegen dem kleinen bisschen Magic, der einem das Leben leichter macht. Aber auch hier muss man manchmal tricksen bzw. bricht sich einen ab, wenn man nicht genau weiss, was Sache ist. Ich empfinde das einkompilierte Zeugs von Delphi als grenzwertig, aber eben noch auf der 'guten Seite'.

Einerseits wäre es sicherlich hilfreich, Records irgendwie initialisieren zu können, nur wann soll das geschehen? Wird dann nicht auch redundanter Code produziert? Einfaches Beispiel:

Delphi-Quellcode:

Var
  A,B : TSomeRecordWithAutoInit;

Begin
  A.Feld := 123;
  B := A;
End;

Wenn der Code sozusagen vor dem 'Begin' ausgeführt wird, dürfte der Init-Code für B überflüssig sein (wegen der Zuweisung von A). Wenn der code also redundant wäre, könnte (und sollte) er wegoptimiert werden. Wann wird also *genau* der Init-Code von 'B' ausgeführt? Wird er überhaupt ausgeführt (wegen der letzten Zeile) oder von Delphi wegoptimiert?

Klarer und eindeutiger wäre es so:

Delphi-Quellcode:

Var
  A,B : TSomeRecordWithoutAutoInit;

Begin
  A.Init;  // Klare Ansage.
  A.Feld := 123;
  B := A;  
End;

Wie gesagt, nur meine konservative bescheidene Meinung.

[mkinzler]

Imho sollte man die Unterschiede zwischen Klassen und Records nicht weiter verwischen. Wer einen Konstruktor will, sollte eine Klasse nehmen. Statt A.Init; wäre dann eine generisches Init( A); besser