Delphi 11 versteht mein generic nicht mehr

[Stevie]

Zitat von Rollo62:

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

Zitat von sakura:

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 class constraint zu T hinzu, dann merkt der Compiler, dass es sich nur um ein Objekt handeln kann und ist zufrieden.

[Elrond]

Zitat von Stevie:

@Elrond:
Füge einfach noch den 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

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 von Elrond:

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 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 TObject als constraint angeben kann und anstatt dessen einen E2510 bekommt und constructor alleine nicht 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 von himitsu:

<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 class zu 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 record wäre dabei natürlich immer noch außen vor, aber das ist wohl auch gar nicht so schlecht.

[Elrond]

Zitat von 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.

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).