Variable.Create;

[Medium]

Dort wo Referenzzählung oder ggf. sogar ein Owner ins Spiel kommt, sind auch Dinge wie TMyClass.Create(someArgument).SomeMethod(someMoreArguments); denkbar. Und dann stelle man sich vor, SomeMethod() hätte auch noch einen Rückgabewert. Solche Konstrukte habe ich in C# nicht allzu selten benutzt, wenn ich von einer Klasse nur diese eine Funktion eben schnell brauchte. Mit Interfaces sicherlich ähnlich vorstellbar.

[himitsu]

Wenn SomeMethod ein Constructor ist, dann hast du dort die selben Probleme wie bei Variable.Create .

Es kommt ja letztendlich, nach dem Compiler, auch wieder auf Folgendes raus. (nur daß hier das Temp initialisiert sien sollte)

Delphi-Quellcode:

Temp := TMyClass.Create(someArgument);
Temp.SomeMethod(someMoreArguments);

[jfheins]

Der Konstruktor sollte einfach nach außen hin statisch bzw. in Delphi-Ausdrücken sowas wie eine Klassenmethode sein.

Das Aufrufen auf eine Instanzvariable ergibt dann einfach den Compilerfehler "Instanzmethode 'Create' nicht gefunden, meinten Sie vielleicht den Konstruktor der Klasse ..."
Innerhalb des Konstruktors muss man dann natürlich auf die Felder zugreifen können.

Ist aber natürlich ein "Breaking Change", und alte Versionen (deren Nutzer es vielleicht eher brauchen) bekommen sowas nicht mit...

Ach ja und bei sowas:

Delphi-Quellcode:

var
  Reg : TRegistry;
begin
 Reg.Create; // Compilerfehler bitte hier!
  try
   Reg.RootKey:=HKEY_CLASSES_ROOT;
   Reg.OpenKey('.htm', true);
   Edit1.Text:=reg.ReadString('');
  finally
   reg.Free;
  end;
end;

MUSS doch ein Compilerfehler kommen wie "Verwendung der nicht zugewiesenen lokalen Variablen 'Reg'" !?
Aber vermutlich bin ich auch nur von C# verwöhnt

[Medium]

Ups, mir fiel erst jetzt auf, dass du den Konstruktor im ersten Beispiel auf die Variable angewendet hast. Das war mir schon so abwegig, dass mein Hirn das vermutlich automatisch anders verstehen wollte (Ich hab das so gesehen, dass du dort nur die Zuweisung der Instanz an eine entsprechende Variable weg gelassen hast.)
Da stimme ich dann voll zu. Wenn sich die Konstruktoren von ggf. anderen Factory-Methoden der Klasse unterscheiden lassen (was imho in allen Sprachen so sein dürfte), dann gehört dort definitiv eine "nicht initialisiert" Meldung hin.

[Sir Rufo]

Auszug aus der Dokumentation

Zitat:

Wenn Sie einen Konstruktor mit einer Objektreferenz (anstatt mit einer Klassenreferenz) aufrufen, wird kein Objekt erstellt. Stattdessen werden, wie bei einer normalen Routine, die angegebenen Anweisungen mit dem Objekt ausgeführt, und es wird eine Referenz auf das Objekt zurückgegeben. Beim Aufruf mit einer Objektreferenz wird normalerweise der geerbte Konstruktor mit inherited ausgeführt.

Das ist also ein gewolltes Verhalten ... darum stehen die Chancen auf eine Warnung/Fehlermeldung eher schlecht.

Benutzen könnte man das um die Instanz erneut zu initialisieren ... habe ich aber noch nie gemacht, und werde ich auch nicht machen

PS

Ich werde morgen mal versuchen bei einer Komponenten so den Owner zu wechseln, wenn das dann in irgendeiner Art nicht funktioniert, dann schreibe ich einen QC-Eintrag

[Medium]

Unabhängig davon wäre dennoch zumindest eine Warnung angebracht, wenn der Konstruktor einer nicht initialisiertern Variablen aufgerufen wird, wie Himi es eingangs glaube ich meinte. Es mag zwar einer statischen Methode ähneln, aber eine neu initialisierte ungültige Referenz bleibt eine ungültige Referenz.

[BUG]

Zitat von Sir Rufo:

Ich werde morgen mal versuchen bei einer Komponenten so den Owner zu wechseln, wenn das dann in irgendeiner Art nicht funktioniert, dann schreibe ich einen QC-Eintrag

Da steht nirgendwo, dass auch der Destructor ausgeführt wird, also hast du schlechte Karten.

[jaenicke]

Zitat von BUG:

Da steht nirgendwo, dass auch der Destructor ausgeführt wird, also hast du schlechte Karten.

Das wiederum geht mit DisposeOf, auch wenn es nicht empfohlen wird das zu nutzen. Damit wird der Destruktor aufgerufen. Ob das mit dem Konstruktoraufruf wieder rückgängig gemacht wird?

[jfheins]

Zitat von Sir Rufo:

Auszug aus der Dokumentation
[...]
Das ist also ein gewolltes Verhalten ... darum stehen die Chancen auf eine Warnung/Fehlermeldung eher schlecht.

Ja, dieses Verhalten ist wirklich ... praktisch.

Ich hoffe, von euch ist keiner auf die bescheuerte Idee gekommen, in Konstruktoren ungeprüft irgendwelche Unterobjekte zu erzeugen. Weil das würde dann ja zu Speicherlecks führen sobald man .Create aufruft

Also immer schön:

Delphi-Quellcode:

constructor TMyClass.Create();
begin
   inherited Create; //hierdurch wird der ursprüngliche Konstruktor aufgerufen
   if not Assigned(values)
      values = TStringList.Create();
   if not Assigned(nodes)
      nodes = TObjectList.Create();
end;

Oder irre ich mich da?

[Stevie]

Zitat von jfheins:

Ach ja und bei sowas:

Delphi-Quellcode:

var
  Reg : TRegistry;
begin
  Reg.Create; // Compilerfehler bitte hier!
  try
    Reg.RootKey:=HKEY_CLASSES_ROOT;
    Reg.OpenKey('.htm', true);
    Edit1.Text:=Reg.ReadString('');
  finally
    Reg.Free;
  end;
end;

MUSS doch ein Compilerfehler kommen wie "Verwendung der nicht zugewiesenen lokalen Variablen 'Reg'" !?
Aber vermutlich bin ich auch nur von C# verwöhnt

Zitat von Medium:

Unabhängig davon wäre dennoch zumindest eine Warnung angebracht, wenn der Konstruktor einer nicht initialisiertern Variablen aufgerufen wird, wie Himi es eingangs glaube ich meinte. Es mag zwar einer statischen Methode ähneln, aber eine neu initialisierte ungültige Referenz bleibt eine ungültige Referenz.

Ich weiß gar nicht, was ihr habt, im Beispiel oben kommt:
W1036 Variable 'Reg' might not have been initialized