Delphi-PRAXiS
Seite 1 von 5  1 23     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Variable.Create; (https://www.delphipraxis.net/179403-variable-create%3B.html)

himitsu 5. Mär 2014 13:14

Delphi-Version: 7

Variable.Create;
 
Meint ihr, es würde was bringen, wenn man Emba dazu überredet, die mögen doch endlich mal eine (abschaltbare) Compilerwarnung anzeigen?

Bei
Delphi-Quellcode:
Variable.Create;
statt
Delphi-Quellcode:
Variable := TTyp.Create;



Guuuut, denen, die da am Meisten drauf reinfallen, wird es eh nie helfen, denn
- es gibt ja sowieso kein Update für alte Delphi-Versionen (D7, D5 usw.)
- und die Anfänger gucken eh selten in das CompilerLog

mkinzler 5. Mär 2014 13:19

AW: Variable.Create;
 
Wobei das 1. ja nicht falsch ist. Es macht halt in den meisten Fällen halt nicht was der Programmierer damit beabsichtigt.

DeddyH 5. Mär 2014 13:21

AW: Variable.Create;
 
Ist das nicht eigentlich immer falsch? Mir fällt spontan kein Anwendungsfall ein, da es doch immer in einer AV enden müsste. Bei TTyp.Create ohne Zuweisung an eine Variable sieht das Fall anders aus.

[edit] Nee, meine Aussage stimmt nicht ganz, wenn die Instanz bereits existiert, würde der Konstruktor noch einmal durchlaufen. Aber wozu braucht man das? [/edit]

himitsu 5. Mär 2014 13:21

AW: Variable.Create;
 
Ja, darum auch nur als Warnung/Hinweis und eventuell "abschaltbar".

"Meistens" wäre es ja falsch.


Wenn man die Variable vorher entsprechend initialisiert, wäre dieser Aufruf möglich.
Man kann damit z.B. erzwingen, daß die "neue" Instanz an einer bestimmten Adresse liegt. (man könnte das Objekt sogar in eine MMF oder in einen Record verfrachten)

uligerhardt 5. Mär 2014 13:25

AW: Variable.Create;
 
Da gibt's ein paar Spezialitäten zu beachten:
  1. Delphi-Quellcode:
    inherited Create
    fällt ja streng genommen auch in diese Kategorie (also Konstruktoraufruf mit schon bestehender Instanz), denn es entspricht ja
    Delphi-Quellcode:
    TBaseClass(Self).Create
    .
  2. Ich verwende öfter delegierende Konstruktoren, so etwa:
    Delphi-Quellcode:
    constructor TDings.CreateWithLotsOfArgs(...);
    begin
      inherited Create;
      //...
    end;

    constructor TDings.Create;
    begin
      CreateWithLotsOfArgs(IrgendwelcheDefaultArgumente); // ***
    end;
    Und der Aufruf *** ist ja auch von der Sorte Variable.Create mit Variable = Self. Für den möchte ich aber keine Warnung.

Medium 5. Mär 2014 13:49

AW: Variable.Create;
 
Dort wo Referenzzählung oder ggf. sogar ein Owner ins Spiel kommt, sind auch Dinge wie
Delphi-Quellcode:
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 5. Mär 2014 14:00

AW: Variable.Create;
 
Wenn SomeMethod ein Constructor ist, dann hast du dort die selben Probleme wie bei
Delphi-Quellcode:
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 5. Mär 2014 14:41

AW: Variable.Create;
 
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 :stupid:

Medium 5. Mär 2014 15:06

AW: Variable.Create;
 
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 :stupid: (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 5. Mär 2014 23:55

AW: Variable.Create;
 
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
Delphi-Quellcode:
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 ;)


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:08 Uhr.
Seite 1 von 5  1 23     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz