Sonderzeichen in TEdits (Charset?)

[himitsu]

Nee, leider gibt es keine Möglichkeit, um bei den Generics Nummern zu übergeben.
Und wenn man den Speicher als String[x] oder array[0..x] of Char als Parameter übergibt, dann kann man nicht innerhalb des generischen Typs darauf zugreifen, um die nötigen Konvertierungen für die Operatoren zu implementieren.

Praktisch sind die Generics dafür komplett nutzlos.

Von der Sprache/Syntax her wäre es schon möglich den Generigs etwas von Makros mitzugeben oder eben, daß man nicht nur Typen, sondern auch Werte (Nummern oder Strings) als "Parameter" an den Generic übergibt ... aber ob Emba jemals sowas Cooles in die Generics einbaut? (wäre immerhin ein Pluspunkt gegenüber den anderen Programmiersprachen, welche Generics kennen)

Der Einzige Ausweg blieb halt nur noch ein "blödes" Template, über welches man sich zumindestens passende Typen basteln könnte.



Da die Generics nur einmal geparst und sofort auf Syntax und Typverträglichkeit geprüft werden, wo der ersetzende Typ noch nichtmal bekannt ist, kann man da innerhalb der Generics leider nicht viel machen.
Ein mehrschichtiger Parser würde mir in Delphi wirklich gefallen, welcher die Typkompatibilität erst nach dem Ersetzen der generischen Typen prüft.

[uligerhardt]

Zitat von himitsu:

Nee, leider gibt es keine Möglichkeit, um bei den Generics Nummern zu übergeben.
Und wenn man den Speicher als String[x] oder als array[0..x] of Char übergibt, dann kann man nicht mehr innerhalb des Generischen Typs darauf zugreifen, um die nötigen konvertierungen für die operatoren hinzubekommen.

Ich hatte irgendwann mal sowas wie

Delphi-Quellcode:

FixedSizeUnicodeString<BaseT> = record
public
  const cBaseSize = SizeOf(BaseT);
strict private
  FBuffer: array[0..Pred(cBaseSize)] of WideChar;
end;

, was sich zumindest compilieren ließ. Aber leider war cBaseSize immer 0, egal, welchen Typ man übergeben hat. Experimente mit constraints (z.B. FixedSizeUnicodeString<BaseT: record> ) haben das - WIMRE - behoben, sich aber nie für BaseT = string[N] compilieren lassen.

Zitat von himitsu:

Von der Sprache/Syntax her wäre es schon möglich den Generigs etwas von Makros mitzugeben oder eben, daß man nicht nur Typen, sondern auch Werte (Nummern oder Strings) als "Parameter" an den Generic übergibt ... aber ob Emba jemals sowas Cooles in die Generics einbaut? (wäre immerhin ein Pluspunkt gegenüber den anderen Programmiersprachen, welche Generics kennen)

Manchmal vermisse ich echt C++.

Zitat von himitsu:

Der Einzige Ausweg blieb halt nur noch ein "blödes" Template, über welches man sich zumindestens passende Typen basteln könnte.

Da wir string[N] nur für eine Handvoll unterschiedliche N's brauchen, könnte ich mich ja mit etwas Copy&Paste arrangieren. Vielleicht kann man auch mit twm's Pseudo-Templates was tricksen.

[himitsu]

Zitat:

Ich hatte irgendwann mal sowas wie

Sowas ähnliches hatte ich auch mal ausprobiert, mit dem Ergebnis, daß sich sporadisch im Code "internal copiler error" versteckten.

Das Problem ist halt, daß BaseT zur Compilezeit und an dieser Stelle noch nicht bekannt ist.
Leider arbeitet der Compiler nur in einem Durchgang, so daß der Code nicht nochmal übersetzt wird ... SizeOf bekommt also niemals den Ersatztypen mit, welchen man bei einer späteren Verwendung des GenTyps angibt.


Leider fehlt mir auch die Zeit, um mich mal mit einem Precompiler für Delphi zu beschäftigen und zu schauen, ob sich da etwas machen ließe.
(hatte zwar mal einen PreCompiler für D2005 oder 2006 gefunden, aber wenn ich jetzt suche, dann finde ich nur noch Welche für die alten Compiler ala D7 und das funktioniert unter neueren Delphis nicht mehr und ist meistens auch "unschön" gelöst)

[uligerhardt]

Zitat von himitsu:

Das Problem ist halt, daß BaseT zur Compilezeit und an dieser Stelle noch nicht bekannt ist.
Leider arbeitet der Compiler nur in einem Durchgang, so daß der Code nicht nochmal übersetzt wird ... SizeOf bekommt also niemals den Ersatztypen mit, welchen man bei einer späteren Verwendung des GenTyps angibt.

Nö, prinzipiell kennt der Compiler die Größe von BaseT schon. Noch ein (seeeehr) experimenteller Stand war nämlich sowas:

Delphi-Quellcode:

FixedSizeUnicodeString<BaseT> = record
strict private
  FBufferPart1: T;
  FBufferPart2: T;
end;

Dann hatten Instantiierungen von FixedSizeUnicodeString zumindest die richtige SizeOf. Dafür hat's dann wieder woanders gehakelt, mal abgesehen davon, dass das eine Move/FillChar/Cast/Pointerarithmetik-Orgie geworden wäre.
Aus irgendeinem Grund verrät der Compiler uns aber die Größe nicht, auch wenn er sie kennt.