Generics nicht in SubRecords verfügbar.

[himitsu]

Ein bissl Individualität kann nie schaden.


Ich versteh die Genericks "manchmal" nicht.

Jetzt sind och noch generische Konstruktoren verboten.

Zitat:

[DCC Fehler] RegEx.pas(654): E2528 Typparameter sind bei dieser Methode nicht erlaubt

Was für einen Sch*** haben die da eigentlich zusammengebastelt.

[himitsu]

@USchuster:
Nee, ich glaub ich nehm doch eine externe Variante.

Nachdem ich jetzt die Unit umgebaut und wieder kompilierbar hatte, da kam dieses raus:
[DCC Fataler Fehler] RegEx.pas(4250): F2084 Interner Fehler: URW1111 Allerdings meldete sich der Compiler hier erst nach dem End. und ich brauchte eine Weile um es auf diese Zeilen zurückzuführen.


nun sieht es also so aus

Delphi-Quellcode:

TReplacerData<Str> = Array[-1..1024] of Record
  Pos, Len: Integer;
  S:        Str;
End;
TReplacer<Str> = Record
Private
  _Data:  TReplacerData<Str>;
  _Count: Integer;
  _S:     ^Str;
Public
  Procedure Initialize(Var S: Str);
  Procedure Repleace(Pos, Len: Integer; Const S: Str; Var DoOffset: Integer);
  Function  Finalize: Integer{Offset};
End;
TReplacer   = TReplacer<String>;
TReplacerCP = TReplacer<CPString>;

[Stevie]

Pointer auf generische Typparameter gehen nicht, warum erklärt Barry Kelly hier (erster Kommentar)

P.S.: Nen Tip: Vergiss Delphi 2010 für solche abenteuerlichen Generic Versuche, das bringt nur Ärger (ich spreche aus Erfahrung)

[himitsu]

In D2010 soll sich doch einiges gebessert haben?
In D2009 hatte ich noch mehr Probleme und XE hab ich immernoch nicht getestet.

[Stevie]

In Delphi 2010 waren Generics ansatzweise benutzbar. Trotzdem bin ich bei meiner Implementierung von generischen Events und einem Nachbau von Linq-to-SQL alle Nase lang auf lustige Internal Errors des Compileres gestoßen. Die schlimmsten Kandidaten, die ich aufgrund dieser Fehler irgendwann auf Eis gelegt habe sind zumindest ohne Probleme in XE kompilierbar. *auf Holz klopf*

[mkinzler]

http://tech.turbu-rpg.com/187/a-plea...with-delphi-xe

[USchuster]

@himitsu:
Der Compiler unterstützt parametrisierte Methoden, aber keine parametrisierte Konstruktoren oder Destruktoren. C# erlaubt das im übrigen auch nicht und damit ist das mit S-Wort etwas unpassend.

Generics werden pro Unit instanziert wo diese verwendet werden und der Code ist dann praktisch nach dem Ende der eigentlichen Unit. Daher ist es bei internen Generics Compilerfehlern nicht verwunderlich das diese auch mal eine Zeile nach dem Unitende gemeldet werden. Den Fehler kann ich nachvollziehen. Leider habe ich den Fehler gestern nicht bekommen, da ich im Projektquelltext getestet habe und der URW Fehler nur auftritt wenn sich die Rekorddefinition in einer Unit befindet. Bei internen Compilerfehlern bleibt i.d.R. nicht anderes übrig als den Code abzuändern.

Wer legt nun die QC Einträge dazu an?

@Stevie:
Es handelt sich um einen Pointer für einen Typparameter und der aufgetretene URW Fehler hat damit gar nichts zu tun.

[himitsu]

Ich hab schon ein paar QTs, aber seitens Emba noch nie was gehört und in XE wurde es wohl auch nicht behoben, da diese QTs noch offen sind.
Irgendwie verliert man da die Lust.

[Stevie]

Zitat von USchuster:

@Stevie:
Es handelt sich um einen Pointer für einen Typparameter und der aufgetretene URW Fehler hat damit gar nichts zu tun.

Hab ich auch nicht behauptet.

[USchuster]

@himitsu:
Ich habe die Probleme eingetragen. Rein interessehalber - was sind Deine Top 3 QC Einträge?

Report No: 88028 Status: Reported
E2003 Undeclared identifier: 'T' with type parameter in anonymous record within generic type
http://qc.embarcadero.com/wc/qcmain.aspx?d=88028

Report No: 88029 Status: Reported
E2528 needs to be documented
http://qc.embarcadero.com/wc/qcmain.aspx?d=88029

Report No: 88031 Status: Reported
F2084 Internal Error: URW1136 with nested array of record type with type parameter
http://qc.embarcadero.com/wc/qcmain.aspx?d=88031