Enum in String mehrere Overloaded Funktionen zu einer einzigen zusammenfassen?

[Zacherl]

Zitat von Der schöne Günther:

Man kann den Compiler nicht zufällig anweisen keine Schlussfolgerungen über den generischen Typ anzustellen sodass der Benutzer den generischen Typ angeben muss?

Einen Typ angeben musst du bei einer generischen Klasse ja sowieso zwingend. Das Problem ist, dass die Delphi Generics außer class und interface keine Constraints zulassen. Wobei Constraints eh nur ein Versuch sind ein viel prägnanteres Design-Flow abzuschwächen:

Delphi-Quellcode:

class procedure TGenericClass<TEnum>.Print(Enum: TEnum);
var
  E: TEnum;
begin
  for E := Low(Enum) to High(Enum) do
  begin
    WriteLn(Ord(Enum));
  end;
end;

An dieser Stelle meldet sich der Delphi-Compiler obwohl ich die Klasse nirgends verwende mit einem Fehler, weil er einfach so davon ausgeht, dass TEnum kein Enum-Typ ist, sondern eine Klasse (bzw. untypisiert ist, oder was der Compiler auch immer an dieser Stelle als Standardtyp annimt). Dies ist mir relativ unverständlich, wenn ich mal mit den Templates in C++ vergleiche (diese sind auf der trivialsten Ebene praktisch Generics):

Der Code in Template-Funktionen wird erst dann verifiziert, sobald er auch generiert wird. Und generiert wird er einmalig für jeden distinkten Datentyp den ich tatsächlich irgendwo im Code an die Template-Klasse übergebe.
TGenericClass<TIrgendeinExistierendesEnum>.Print(MyEnum) würde also ohne Probleme funktionieren, während TGenericClass<TIrgendeineKlasse>.Print(MyClassInstance) korrekterweise den Fehler erzeugt, dass man Low natürlich nicht auf einen Klassentyp anwenden darf.

Die C++ Templates sind im Gegensatz zu den Delphi Generics sozusagen Context-aware.

Am Ende kommt jedenfalls bei raus, dass man unter Delphi gezwungen wird ziemlich viele nicht typsichere Operationen durchzuführen, bei denen man höchstens mit viel Mühe und unter Verwendung der RTTI eine teilweise Typsicherheit wiederherstellen kann:
http://www.delphipraxis.net/190944-r...alisieren.html

Edit: @Günther: Und wer hindert dich bei deiner Klasse daran einfach TEnum.GetName<TForm1>(Form1) aufzurufen?

[a.def]

Die Antworten sind ja schon erstaunlich.
Wäre es bei so vielen Komplikationen einen schönen Code zu bekommen nicht die einfachste Möglichkeit mehrere overloaded Funktionen zu fahren?

[Zacherl]

Zitat von a.def:

Wäre es bei so vielen Komplikationen einen schönen Code zu bekommen nicht die einfachste Möglichkeit mehrere overloaded Funktionen zu fahren?

Wir wollten dich nicht verunsichern, sondern nur auf eine mögliche Gefahr hinweisen. Ich würde es trotzdem folgendermaßen lösen:

Delphi-Quellcode:

type
  TEnumHelper<TEnum> = record
    public class function GetName(Value: TEnum): String; overload; static;
  end;

{ TEnumHelper<TEnum> }

class function TEnumHelper<TEnum>.GetName(Value: TEnum): String;
var
  TypInfo: PTypeInfo;
  TypData: PTypeData;
  V: Integer;
begin
  TypInfo := TypeInfo(TEnum);
  {$IFDEF DEBUG}
  if (TypInfo^.Kind <> tkEnumeration) then
  begin
    raise Exception.Create('Invalid generic type.');
  end;
  {$ENDIF}
  TypData := GetTypeData(TypInfo);
  case TypData^.OrdType of
    otSByte,
    otUByte:
      V := PByte(@Value)^;
    otSWord,
    otUWord:
      V := PWord(@Value)^;
    otSLong,
    otULong:
      V := PInteger(@Value)^;
  end;
  Result := GetEnumName(TypeInfo(TEnum), V);
end;

Du solltest halt nur aufpassen, dass du dieser Klasse als Typ tatsächlich nur Enums übergibst und nichts anderes. Im Debug-Mode würdest du zwar im Zweifelsfalle eine Runtime-Exception bekommen, aber bei Code-Pfaden, die nicht oft ausgeführt werden, entdeckt man so einen Laufzeitfehler teilweise erst recht spät.

Alternativ müsste auch das hier gehen:

Delphi-Quellcode:

class function TEnumHelper<TEnum>.GetName(Value: TEnum): String;
var
  TypInfo: PTypeInfo;
  V: Integer;
begin
  TypInfo := TypeInfo(TEnum);
  {$IFDEF DEBUG}
  if (TypInfo^.Kind <> tkEnumeration) then
  begin
    raise Exception.Create('Invalid generic type.');
  end;
  {$ENDIF}
  case SizeOf(TEnum) of
    1: V := PByte(@Value)^;
    2: V := PWord(@Value)^;
    4: V := PInteger(@Value)^;
  end;
  Result := GetEnumName(TypeInfo(TEnum), V);
end;

[uligerhardt]

Dumme Frage: Warum nimmst du statt dem:

Zitat von Zacherl:

Delphi-Quellcode:

  {$IFDEF DEBUG}
  if (TypInfo^.Kind <> tkEnumeration) then
  begin
    raise Exception.Create('Invalid generic type.');
  end;
  {$ENDIF}

nicht einfach Assert?
  Assert(TypInfo^.Kind = tkEnumeration, 'Invalid generic type.');

[Zacherl]

Zitat von uligerhardt:

Dumme Frage: Warum nimmst du nicht einfach Assert?
  Assert(TypInfo^.Kind = tkEnumeration, 'Invalid generic type.');

Guter Einwand Keine Ahnung, warum ich das so umständlich gemacht hatte.

[a.def]

Kann man diese Funktion auch in mein aktuell bestehendes Konzept einbauen?

Delphi-Quellcode:

unit enum_functions;

uses ;

type
 TEnumFunctions = class
 private
  //
 public
  // meine Funktionen
 end;

implementation

// meine Funktionen

end;

Delphi-Quellcode:

var _enumFunctions: TEnumFunctions;

// Aufruf meiner Funktionen mit
_enumFunctions.Funktionsname();

[Zacherl]

Zitat von a.def:

Kann man diese Funktion auch in mein aktuell bestehendes Konzept einbauen?

Natürlich kannst du dir die Funktion auch in deine bestehende Klasse einbauen. Wenn du dir allerdings Sorgen machst, dass du bei der Helper Klasse von mir zusätzliche Instanzen pflegen musst, dann kann ich dich beruhigen, da du die Funktion ganz einfach in der Form S := TEnumHelper<TMyEnum>.GetName(EnumValue) aufrufen kannst.

In deiner bestehender Klasse müsstest du dann die Funktion selbst mit Generics ausrüsten, anstelle der ganzen Klasse (sofern die anderen Helper nicht auch typisiert werden sollen).

Generell würde ich dir allerdings raten deine TEnumFunctions mit class function Bla: X; static bzw. class procedure Bla; static auszurüsten statt der normalen Methoden. Dann benötigst du auch dafür keine Instanz mehr, was die Aufrufe zum einen weniger umständlich macht und dir später im Kompilat sogar ein klein wenig (nagut nur sehr sehr wenig - aber immerhin ) Performance-Overhead einspart.
Letzter Tipp natürlich unter dem Vorbehalt, dass du wirklich keine Instanz (also z.b. Zugriff auf Klassen-Felder, persistenter State, etc.) benötigst.

[a.def]

Zitat von Zacherl:

Generell würde ich dir allerdings raten deine TEnumFunctions mit class function Bla: X; static bzw. class procedure Bla; static auszurüsten statt der normalen Methoden. Dann benötigst du auch dafür keine Instanz mehr, was die Aufrufe zum einen weniger umständlich macht und dir später im Kompilat sogar ein klein wenig (nagut nur sehr sehr wenig - aber immerhin ) Performance-Overhead einspart.

Daran hatte ich schon lange gedacht. Denn mit meiner aktuellen Klasse+Instanz kann ich nur Funktionen und Prozeduren einbauen, aber keine private und public Variablen.
Nur ich weiß leider nicht wie das geht

Zitat:

Letzter Tipp natürlich unter dem Vorbehalt, dass du wirklich keine Instanz (also z.b. Zugriff auf Klassen-Felder, persistenter State, etc.) benötigst.

Das habe ich nicht ganz verstanden. Aber ich glaube du meinst, dass man dann keine Variablen im TEnumFunctions = class-Konstrukt benutzen kann.

Edit: habs glaube ich

Delphi-Quellcode:

type
 TEnumFunctions = class
 private
  //
 public
  class function TestFunction(sInput: string): string; static;
 end;

implementation

class function TEnumFunctions.TestFunction(sInput: string): string;
begin
 Result := sInput + ' - ZUSATZ';
end;

// Aufruf
ShowMessage(TEnumFunctions.TestFunction('123'));

... bin gerade schon alles fleißig am umstellen, damit ich die Instanzen-"Variable" loswerde.

Sollte dann lieber folgendes bleiben...

Delphi-Quellcode:

type
 TEnumFunctions = class

Oder besser

Delphi-Quellcode:

type
 TEnumFunctions = record

?