Delphi 11 versteht mein generic nicht mehr

[Elrond]

Hallo Zusammen,

ich habe heute neben meiner Delphi Version 10.3 die neue 11 installiert und wollte schauen ob mein Projekt durchcompliert.

Es hat sich scheinbar im Umgang mit generics etwas geändert, weswegen er bei meiner generische Implementierung eines Singleton scheitert und mir den Fehler liefert:

E2010 Inkompatible Typen: 'TObject' und 'T'

Hier der vollständige kurze Quelltext:

Delphi-Quellcode:

type 
  IOrModel = interface
    ['{2901ade0-0373-491a-8624-1ece11c1ddbd}']
  end;

  TModel<T: IOrModel, constructor> = class abstract
  private
    class var Model: T;

  public
    class function GetInstance: T;
    class procedure ReleaseInstance();
  end;

implementation

class function TModel<T>.GetInstance: T;
begin
  if not Assigned(Model) then
    Model := T.Create;

  Result := Model;
end;

class procedure TModel<T>.ReleaseInstance;
begin
  if Assigned(Self.Model) then
  begin
   FreeAndNil(Self.Model);//für hier kommt die Fehlermeldung
  end;

end;

end.

Hat jemand eine Idee was sich geändert hat? Konnte in den Updatenotes nichts finden.

Viele Grüße
Alexander

[Rollo62]

Delphi-Quellcode:

T: IOrModel

Ist ein Interface, da sollte Self.Model := nil; reichen.

[Uwe Raabe]

Das wurde schon in 10.4 geändert: FreeAndNil

[sakura]

Zitat:

Zitat von Uwe Raabe (Beitrag 1496251)

Das wurde schon in 10.4 geändert: FreeAndNil

Das es vorher kompilierte, das war ein Bug und hätte in Deinem Fall eigentlich zu einer AV führen sollen.

...:cat:...

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1496247)

Delphi-Quellcode:

T: IOrModel

Ist ein Interface, da sollte Self.Model := nil; reichen.

Zitat:

Zitat von sakura (Beitrag 1496253)

Dass es vorher kompilierte, das war ein Bug und hätte in Deinem Fall eigentlich zu einer AV führen sollen.

Nein, der constructor Contraint sorgt dafür, dass es sich bei T nur um eine Klasse handeln kann. Diese muss nur auch das IOrModel Interface implementieren - da ich davon ausgehe, dass der Code bisher funktioniert, werden diese Klassen dann wohl keine Referenzzählung implementieren.

@Elrond:
Füge einfach noch den

Delphi-Quellcode:

class

constraint zu T hinzu, dann merkt der Compiler, dass es sich nur um ein Objekt handeln kann und ist zufrieden.

[Elrond]

Danke für die Antworten!

Was ich mich aber Frage, dieses Singleton ist eine abstrakte Klasse und die Klassen die davon abgeleitet sind, verzichten auf eine Referenzzählung.
Damit würde ich eigentlich das Objekt nicht mehr freigeben und müsste die Referenzzählung wieder aktivieren.

[Elrond]

Zitat:

Zitat von Stevie (Beitrag 1496267)

@Elrond:
Füge einfach noch den

Delphi-Quellcode:

class

constraint zu T hinzu, dann merkt der Compiler, dass es sich nur um ein Objekt handeln kann und ist zufrieden.

Super das hat geklappt :thumb:

Kleine Anmerkung noch, kann es sein das die Angabe von constructor deswegen nicht mehr reicht, weil jetzt auch Records Konstruktoren haben dürfen?

[himitsu]

Records dürfen das schon lange haben. (dort aber leider nicht, wenn ohne Parameter)

Wobei es dort "nur" Constructor heißt, aber Keiner ist.




Das "< ,constructor>" nur wegen dem FreeAndNil?
FreeAndNil war doch schon immer falsch, wenn dort Interfaces drin sind.


Das Problem mit FreeAndNil und "kein Object" kann nun daran liegen, dass dessen Signatur geändert wurde,
und da inzwischen ausschließlich Objekte übergeben werden können. (vorher war es ein typloser Parameter)

[Stevie]

Zitat:

Zitat von Elrond (Beitrag 1496271)

kann es sein das die Angabe von constructor deswegen nicht mehr reicht, weil jetzt auch Records Konstruktoren haben dürfen?

Nein, der constructor Constraint besagt, dass der Typ einen parameterlosen Konstruktor haben muss und das können Records sowieso nicht.
Dass es nicht mehr kompiliert liegt an der Änderung von

Delphi-Quellcode:

FreeAndNil

, was nun nicht mehr einen typenlosen var Parameter entgegen nimmt.
Semantisch hast du schon vorher sichergestellt, dass T nur eine Klasse sein kann, aber nicht syntaktisch, weswegen der Compiler das nun nicht mehr akzeptiert hat.

Um noch ein bisschen auszuholen, warum der constructor Contraint nicht class beinhaltet: die Constraints bei Generics wurden seinerzeit aus .Net übernommen, als Delphi noch in diese Richtung Avancen hatte.
Dabei haben die Entwickler leider einige kleine Klinken eingebaut:
In C# bedeutet der class constraint, dass es sich um einen Referenztypen(!) handeln muss (ja, das sind dann auch interfaces). Wenn man dort nur Klassen haben will, dann muss man einfach Object (oder die entsprechende Basisklasse) angeben.
Diesem kleinen Unterschied ist es wohl auch geschuldet, dass man nicht

Delphi-Quellcode:

TObject

als constraint angeben kann und anstatt dessen einen E2510 bekommt und

Delphi-Quellcode:

constructor

alleine nicht

Delphi-Quellcode:

class

impliziert.

Siehe auch: https://docs.microsoft.com/de-de/dot...ype-parameters

[himitsu]

<IOrModel> nimmt doch nur diesen Typen oder Nachfahren an?

Und da IOrModel ein Interface ist, war und ist Free doch eh falsch?