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?

[Elrond]

Zitat:

Zitat von himitsu (Beitrag 1496296)

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

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

Kommt drauf an, wenn man die Referenzzählung lässt dann ja. Da es sich um ein singleton handelt erschien es mir Sinnvoll auf die Referenzzählung zu verzichten, ich muss mich also selber um die Freigabe kümmern. Besonders da ich auch parallel mit anderen Sprachen arbeite, verzettle ich mich mit den Delphi Interfaces immer wieder.



@Stevie
Danke für die schöne Erklärung, bei Spring4D merkt man das du der Master bist, hab es am Anfang als Grundframework verwendet für viele Aufgaben, aber ich hab nicht alle Mechanismen durchgeblickt und bin auf einfache eigene Lösungen umgestiegen ^^'
Von dort hab ich das auch mit den constructor her und entsprechend so interpretiert das es erzwingt das T eine Klasse ist.

[himitsu]

FreeAndNil setzt(e) zwar die Variable auf NIL,
aber ein Interface bekommt davon nichts mir, da dabei Intf._Relase nicht aufgerufen wird.

Außerdem wird Obj.Destroy ausgeführt, bzw. wird versucht, aber das gibt es ja im Interface so garnicht, also eigentlich müsste es hier auch schön knallen,
wenn in der Variable wirklich ein Interface steckt, anstatt einer Objekt-Referenz.

[Uwe Raabe]

Eventuell wäre sowas in System.Sysutils etwas resilienter gewesen gegenüber einem Wechsel von

Delphi-Quellcode:

class

zu

Delphi-Quellcode:

interface

oder umgekehrt:

Delphi-Quellcode:

procedure FreeAndNil(const [ref] Obj: TObject); inline; overload;
procedure FreeAndNil(const [ref] Obj: IInterface); inline; overload;

...

procedure FreeAndNil(const [ref] Obj: IInterface); overload;
begin
  IInterface(Pointer(@Obj)^) := nil;
end;

Ein

Delphi-Quellcode:

record

wäre dabei natürlich immer noch außen vor, aber das ist wohl auch gar nicht so schlecht.

[Elrond]

Zitat:

Zitat von himitsu (Beitrag 1496314)

FreeAndNil setzt(e) zwar die Variable auf NIL,
aber ein Interface bekommt davon nichts mir, da dabei Intf._Relase nicht aufgerufen wird.

Außerdem wird Obj.Destroy ausgeführt, bzw. wird versucht, aber das gibt es ja im Interface so garnicht, also eigentlich müsste es hier auch schön knallen,
wenn in der Variable wirklich ein Interface steckt, anstatt einer Objekt-Referenz.

Ob das Intf._Release davon was mitbekommt, spielt ja keine Rolle wenn man auf die Referenzzählung verzichtet. Meine Implementierung von _Relase ist einfach Result := -1;

Die Freigabe erfolgt auch auf ein Objekt, das ist mit den constraints für T sichergestellt, deswegen kann ich auch ein Objekt vorher erzeugen ( T.Create).

[himitsu]

Das Problem ist, dass FreeAndNil halt nur für Objekte arbeitet(e).

Jetzt mit der neuen Signatur, wäre eine Unterscheidung zwischen Interface und Objekt möglich. (siehe Post vom Uwe)

Zitat:

Delphi-Quellcode:

procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

Rein logisch macht es einfach

Delphi-Quellcode:

procedure FreeAndNil(var Obj);
begin
  if Assigned(Pointer(Obj)) then TObject(Obj).Destroy;  // TObject(Obj).Free;
  Pointer(Obj) := nil;
end;

// OK, eigentlich
begin
  try
    if Assigned(Pointer(Obj)) then TObject(Obj).Destroy;  // TObject(Obj).Free;
  finally
    Pointer(Obj) := nil;
  end;
end;

Und wenn jetzt in Obj aber ein IInterface liegt, dann kann es beim

Delphi-Quellcode:

TObject(Obj).Destroy;

nur Probleme geben.

Also erstmal knallt es und da

Delphi-Quellcode:

Pointer(Obj) := nil;

die Referenzzählung nicht macht,
welche beim

Delphi-Quellcode:

IInterface(Intf) := nil;

eigentlich auch noch intern ein

Delphi-Quellcode:

if Assigned(Pointer(Intf)) then IInterface(Obj)._Release;

ausführen würde.
OK, wenn man die Zählung ignoriert, dann stört es nicht, falls es vorher nicht schon knallen würde.