Variable mit bestimmbarem Datentyp?

[milos]

Hallo,

ich würde gerne ein Klasse erzeugen bei der ich beim erzeugen einen bestimmten Datentyp wählen kann den ich dann für eine Variable in der Klasse benutzen soll. Also z.B.

Delphi-Quellcode:

var
var1, var2, var3 : TVariable;
begin
var1 := TVariable<string>.Create;
var2 := TVariable<integer>.Create;
var3 := TVariable<TKlasse>.Create;

ShowMessage(var1.Value); // Gibt einen string aus
ShowMessage(IntToStr(var2.Value)); // Einen Integer
ShowMessage(var3.Value.Message); // TKlasse, jedoch wäre "Message" dann ein String
end;

Bin um jeden Tipp dankbar :D

Grüsse,
Milu

Edit: Ich benutze XE6 und nicht Delphi 5 nur mal so als anmerkung :D

[himitsu]

Versuch es mal so:

Delphi-Quellcode:

type
  TVariable = class
  end;

  TVariable<T> = class(TVariable)
  private
    FVar: T;
  public
    constructor Create(Init: T);
  end;

Und zum Edit: Du hättest in den erweiterten Editor umschalten sollen, denn da hättest'e das bestimmt richtig ändern können.

[milos]

Oh cool, danke :D Das geht ja einfach ^^
Leider wusste ich nicht wie man das nennt, und somit hab ich bei der Google suche auch nicht wirklich was gefunden :/

Und das mit dem Erweiterten Editor wusst ich auch noch nicht :oops:

Aber vielen dank ;)

MfG

[himitsu]

Vererbung :zwinker:

Wie bei den anderen Klassen passt ein Nachfahre natürlich nur in Variablen vom selben Typ, oder von Vorfahren.
Und da die generischen Ableitungen quasi jeweils einen "eigenständigen" Typen erzeugen, sind sie untereinander natürlich nicht kompatibel, außer gegen einen der gemeinsamen Vorfahren.


XE6: Macht nichts.
Du könntest das zwar immernoch berichtigen, aber es gibt dort eh noch kein XE6.
Darfst aber gern den Bug-Report puschen: http://www.delphipraxis.net/issue-433/ :stupid:

[Dejan Vu]

Darf ich mal fragen, wozu man soetwas benötigt und warum ein Variant hier nicht infrage kommt?

[milos]

Zitat:

Zitat von himitsu (Beitrag 1266286)

Vererbung :zwinker:

Wie bei den anderen Klassen passt ein Nachfahre natürlich nur in Variablen vom selben Typ, oder von Vorfahren.
Und da die generischen Ableitungen quasi jeweils einen "eigenständigen" Typen erzeugen, sind sie untereinander natürlich nicht kompatibel, außer gegen einen der gemeinsamen Vorfahren.


XE6: Macht nichts.
Du könntest das zwar immernoch berichtigen, aber es gibt dort eh noch kein XE6.
Darfst aber gern den Bug-Report puschen: http://www.delphipraxis.net/issue-433/ :stupid:

Danke für die Info :D
Hab mal gepusht ^^

Zitat:

Zitat von Dejan Vu (Beitrag 1266291)

Darf ich mal fragen, wozu man soetwas benötigt und warum ein Variant hier nicht infrage kommt?

Weil mir die Datentypen die Variant unterstützt nicht ausreichen.

MfG

[himitsu]

Nja, es gibt auch noch den OleVariant, der sich besser für die Kapselung "unbekannter" OLE-Interfaces macht.

Und da Delphi ein Problem mit überlaenen Default-Properties hat (das geht einfach nicht), hatte ich mir auch schonmal einen "varianten" Typen selber gebastelt.

Dank Record-Operatoren ist das eine nette Angelegenheit.
Bei mir war es ein Typ, welcher String und Integer untersützt und das wesentlich leichtgewichtiger, als der große Variant.

[jaenicke]

Zitat:

Zitat von Dejan Vu (Beitrag 1266291)

Darf ich mal fragen, wozu man soetwas benötigt und warum ein Variant hier nicht infrage kommt?

Weil das im Vergleich zu Generics deutlich langsamer wäre und auch keinen Sinn macht, wenn man das Problem mit Generics typsicher und performant lösen kann.

[Dejan Vu]

Zitat:

Zitat von milos (Beitrag 1266376)

Zitat:

Zitat von Dejan Vu (Beitrag 1266291)

Darf ich mal fragen, wozu man soetwas benötigt und warum ein Variant hier nicht infrage kommt?

Weil mir die Datentypen die Variant unterstützt nicht ausreichen.

Das ist ein Argument. Allerdings frage ich mich, wie Du beim Konstrukt

Delphi-Quellcode:

var3.Value.Message

zur Laufzeit auf

Delphi-Quellcode:

Message

zugreifen willst, wo Du doch zur Designzeit gar nicht wissen kannst, das diese Property existiert. D.h. wie würde der konkrete Code denn aussehen?

Zitat:

Zitat von jaenicke (Beitrag 1266378)

Weil das im Vergleich zu Generics deutlich langsamer wäre und auch keinen Sinn macht, wenn man das Problem mit Generics typsicher und performant lösen kann.

Was ihr immer mit eurem 'deutlich langsamer' habt. Es ist nicht 'deutlich' langsamer, sondern höchstens ein wenig und dann auch nur bei Zugriff. Beim Transport fällt das nicht ins Gewicht. Und wenn es sich nicht um Hochgeschwindigkeitsiterationen handelt, ist es eh zweitrangig. Was hier jedoch ins Gewicht fiele, wäre die Tatsache, das alles schon vorhanden ist. 'Performance' spielt auch bei der Entwicklung eine Rolle. Aber jedem sein Bier.
Typsicherheit ist allerdings ein Argument.

Trotzdem würde mich interessieren, wozu man das benötigt, wo man die konkrete variable doch auch quasi direkt erzeugen könnte.

[jaenicke]

Zitat:

Zitat von Dejan Vu (Beitrag 1266381)

Was ihr immer mit eurem 'deutlich langsamer' habt. Es ist nicht 'deutlich' langsamer, sondern höchstens ein wenig und dann auch nur bei Zugriff.

Bei der Zuweisung brauchen Variants ca. 25%-300% mehr Zeit als eine normale Zuweisung. Das kannst du ja leicht selbst prüfen. Je mehr in einer solchen Testschleife noch passiert desto kleiner ist der Unterschied zu Variants. Bei einer reinen Integerzuweisung z.B. kommt man an die 300% heran, bei einem IntToStr zusätzlich eher an die 25%.

Natürlich macht sich das erst bei einer großen Menge an Zuweisungen bemerkbar, da diese ansonsten vernachlässigbar ist. Trotzdem ist es wenig sinnvoll unnötigerweise Variants zu nutzen, wenn es anders geht. Wenn man dann einen solchen Quelltext an einer Stelle nutzt, der mehr Performance benötigt, muss man alles mühsam umstellen, nur weil man ohne Not bewusst die schlechtere Wahl getroffen hat...

[himitsu]

Und bei mir war es auch noch die Typsicherheit, welche bereits im Compiler und nicht erst zur Laufzeit geprüft werden sollte.
Wobei bei mir auch eben nur die beiden Typen (Integer und String) erlaubt waren.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1266281)

Versuch es mal so:

Delphi-Quellcode:

type
  TVariable = class
  end;

  TVariable<T> = class(TVariable)
  private
    FVar: T;
  public
    constructor Create(Init: T);
  end;

Zu dumm nur, dass man mit einem TVariable nicht an den typisierten Value kommt.
Leute, versucht doch nicht immer alle Probleme mit Generics zu erschlagen, wo Generics überhaupt keinen Sinn machen.
Polymorphie und Generics passen nunmal nicht zusammen.

Bei Generics lege ich zur Compiletime fest, welchen Typ ich haben will und nicht zur Laufzeit.
Da würde ich fragen, warum lege ich die Typen der Variablen nicht gleich auf string, Integer und TKlasse fest.

Zum Transport von Werten, wo man zur Compilezeit noch nicht weiß, was dort reinkommt, gibt es TValue. Aber auch dort muss man wieder das herausholen, was man reingepackt hat (

Delphi-Quellcode:

AsType<T>

).

Delphi-Quellcode:

var
  var1, var2, var3: TValue;
begin
  var1 := 'Hello World';
  var2 := 42;
  var3 := myObj;

  ShowMessage(var1.AsString); 
  ShowMessage(IntToStr(var2.AsInteger); // Alternativ: var2.ToString
  ShowMessage(var3.AsType<TKlasse>.Message); 
end;

Bitte dran denken: TValue ist strikt, was Typen angeht, hier findet keine Konvertierung von Typen statt, die nicht direkt zuweisungskompatibel sind (also wenn du z.B. einen Integer rein packst, dann wirft AsString eine Exception). ToString hingegen kann einige Typen zu einem String konvertieren.

[Dejan Vu]

Zitat:

Zitat von jaenicke (Beitrag 1266399)

...Trotzdem ist es wenig sinnvoll unnötigerweise Variants zu nutzen, wenn es anders geht.

Ja und nein (Ansichtssache) Zeit ist Geld und das Rad neu erfinden dauert Zeit, also Geld. Variants sind da und funktionieren. Beim Arbeiten mit Metadaten, also Daten, die Daten definieren, werden deren Werte (hier: die 'Variants') zu 99% transportiert und nur am Anfang und am Ende zugewiesen. Daher wird vermutlich (Glaskugel) der Performanceverlust zweitrangig sein.

Iterationen mit Variants würde ich aber auch nicht machen, und wenn Performance generell eine Rolle spielt, auch nicht. Und da der Umfang der Variants hier nicht ausreichend zu sein scheint, ist das eh alles Theorie.

Ach: Noch ein Argument für Variants: DevExpress, TDatasets etc kommen mit Variants wunderbar zurecht. Würdest Du dir dann eine eigene VCL schreiben? ;-) Oder eine Brücke, damit die generischen Dinger wieder in Variants übersetzt werden? Wieder extra Arbeit, wieder Geld.

[jaenicke]

Zitat:

Zitat von Dejan Vu (Beitrag 1266452)

Ach: Noch ein Argument für Variants: DevExpress, TDatasets etc kommen mit Variants wunderbar zurecht.

Bezüglich TDataSet mussten wir explizit AsString usw. nutzen, da ansonsten bei größeren Datenmengen die Performance in den Keller gegangen ist. Das Beispiel war mir nicht eingefallen, passt aber gut.

[Dejan Vu]

Zitat:

Zitat von jaenicke (Beitrag 1266461)

Bezüglich TDataSet mussten wir explizit AsString usw. nutzen, da ansonsten bei größeren Datenmengen die Performance in den Keller gegangen ist. Das Beispiel war mir nicht eingefallen, passt aber gut.

Wir hatten -glaube ich- schon einmal das Phänomen, das wir gegenteilige Beobachtungen bezüglich einzelner Delphi-Eigenheiten hatten. Ich war mit dem Dataset bisher eigentlich auch bezüglich Performance sehr zufrieden, sofern man das Dataset nicht gebunden hat, 'FieldByName' usw. nicht verwendet etc.