Generics - Pro und Contra

[stahli]

Ich habe ein Projekt, das ich jetzt refakturieren will (muss ).

Eine Dinge habe ich über Generics gelöst - vor allem Listen und Comparer.

Beim Entwickeln und Debuggen hatte ich immer wieder Schwierigkeiten, weil Objekte nicht ohne weiteres zuweisungskompatibel oder Schleifendurchläufe nicht eindeutig nachvollziehbar waren.

Jetzt stellt sich mir die Frage, ob ich lieber auf Generics verzichten sollte.

Sicherlich gibt es dann etwas mehr Schreibarbeit und notwendige Type-Castings an einigen Stellen aber der Programmablauf (nicht der Quelltext) erscheint mir dann nachvollziehbarer.

Ich kenne Generics aus anderen Sprachen nicht, aber im Delphi erscheinen sie mir irgendwie wie ein Fremdkörper.
Man kann zwar mit ihnen durchaus arbeiten, aber im Handling und beim Debuggen wirken sie irgendwie wie eine black box.

Jedenfalls lassen sich klassische Klassen m.E. besser nachvollziehen und händeln.

Wie seht Ihr das?

[jaenicke]

Wir benutzen massiv Generics und haben dadurch deutlich aufgeräumteren und leichter zu debuggenden Code als vorher. Deine Probleme kann ich nur teilweise nachvollziehen. Das einzige Problem, das ich wirklich habe, ist, dass beim Auswerten (Strg + F7) Generics Probleme machen. Aber insgesamt gibt es mit jeder Version Bugfixes an den Generics, das merke ich schon deutlich.
Interne Fehler wie dieser werden auch weniger:
http://qc.embarcadero.com/wc/qcmain.aspx?d=121517

Ein Nachteil von Generics ist, dass die Größe der Anwendungen dadurch spürbar steigt, aber das stört uns nicht wirklich.

[Der schöne Günther]

Das einzige was mir spontan zu "Contra" eingefallen wäre ist die Tatsache, dass es in Delphi komischerweise immer Generics genannt wird, aber tatsächlich Templates sind. Da der Linker wohl auf dem Desktop nicht der schlauste ist werden die Anwendungen dort deutlich größer.

Aber Mich stört es auch nicht.

Der QC-Report war meine Entdeckung

In den ersten XE-Versionen waren (meine ich doch?) Generics noch etwas fehlerbehaftet, aber ich komme eigentlich ganz gut zurecht. Im Debugger sind mir noch nie Probleme aufgefallen. Was meint ihr genau?

Ich könnte mir ehrlich gesagt nicht vorstellen, keine Generics zu haben.

[stahli]

Ich arbeite mit XE3 und ein kostenpflichtiges Update kommt für mich nicht mehr nicht in Frage.

Konkret stört mich, dass beim debuggen von for-in-Durchläufen generischer Listen das tatsächliche Verhalten nicht nachvollziehbar ist.
Z.B. wird auch bei leeren Listen in einen Durchlauf "hinein gesprungen", dieser aber dann wieder abgebrochen.
Danach steht der Debugger dann wieder auf der Ausgangszeile.

Ich kann das nicht ganz genau erklären, da sich mir das Verhalten noch nicht erschlossen sondern mich immer nur genervt hat.

Dann stört mich, dass man keine klaren Klassennamen und Klassenhierarchien (bei Ableitungen) hat.

Mich verwirrt das eher mehr als dass es mir bringt (kann aber natürlich auch mein Problem sein ).

[himitsu]

Jupp, daß Generics eher Templates sind, wo man die Typprüfung schon beim Parsen des Templates macht, anstatt dort nur eine Syntaxprüfung vorzunehmen und die eigentliche Typprüfung erst bei der Verwendung zu machen ... also das ist schrottig und behndert die Nutzung der Generics teilweise extrem.

Was bei den Generics ausfällt, ist daß der Code in der Unit ist, wo der generische Typ entgültig definiert wurde und mir scheint es manchmal auch so, als wenn er dann bei mehreren Units auch mehrmals einkompiliert wird.

Nett ist auch, daß man Debugcode bekommt, obwohl man den für die Unit mit der Definition deaktiviert hat. (ja, der entgültige Code liegt ja nicht in der Unit, aber dennoch hätte man das dann deaktivieren können)


Strg+Linksklick auf eine Methode des generischen Typs leitet einen nicht in die richtige Unit, sondern meistens nur auf das "implementation" der aktuellen Unit.


Bim Zugreifen/Casten innerhalb der generischen Funktionen muß man oftmals die Typprüfung umgehen (mit wilden Pointern referenzieren und gleich wieder dereferenzieren, damit der Cast durch die kranke Typprüfung rutscht. (wenn es sich nicht um Objekte bei dem Typ handelt)



Aber sonst ist das in XE3 schon relativ gut nutzbar. (ist nicht so schlimm, wie die noch verbuggteren Attribute)

[himitsu]

Zitat von stahli:

Konkret stört mich, dass beim debuggen von for-in-Durchläufen generischer Listen das tatsächliche Verhalten nicht nachvollziehbar ist.

Bei nicht generischen Listen passiert das nicht?

Nja, das liegt unter Anderem daran, daß nach der letzten Codezeile der For-In-Schleife der Enumerator freigegeben wird.
Da das ein automatisch generierter Code ist, welcher keine eigene Zeile besitzt, liegt der zufällig an der Position der letzten oder ersten Codezeile der Schleife und für dich sieht es dann halt so aus.
In der Assembleransicht würde das natürlich anders aussehen.

Besser wäre es natürlich, wenn dieser Befehl einfach "übersprungen" und erst wieder an der nächsten richtigen Codezeile angehalten würde.

[stahli]

Bei normalen For-Schleifen wird diese entweder voll durchlaufen oder gar nicht (weiß gar nicht, wie es aktuell mit "for I := 1 to 0 do ..." steht).

Dass bei generischen Listen der Enumerator freigegeben wird habe ich auch schon mal nachvollzogen.
M.E. müsste der Compiler/Debugger das aber intern regeln (so wie bei "while false do begin end").
Für MEINE ANWENDUNG (und die will ich ja debuggen) ist mir ja Wurscht, was der Compiler da intern veranstaltet.
Mit Assembler will ich mich nicht herum schlagen. Deshalb nutze ich ja Delphi.

Ich finde solche unlogischen Verhaltensweisen halt extrem nervig.
Vereinfachen tun sie die Arbeit jedenfalls nicht.


[EDIT]

Jetzt habe ich noch zwei klare Bugs gefunden:
- Wenn eine generische Liste mit einem Eintrag freigegeben wird knallt es, weil zwei Einträge verglichen werden (warum auch immer).
- Das Freigeben eines Comparers verursacht eine Exception (Eurekalog Prof. kann das aber nicht näher auflösen)
(Darüber hinaus habe ich keine Möglichkeit gefunden, einen zugewiesenen Comparer aus einer Liste wieder zu entfernen.)
Ich bin sicher, dass die Fehler nicht durch mich verursacht werden. Kann natürlich möglicherweise in neueren Bezahlversionen schon gefixt sein.

[sx2008]

Zitat von himitsu:

Was bei den Generics ausfällt, ist daß der Code in der Unit ist, wo der generische Typ entgültig definiert wurde und mir scheint es manchmal auch so, als wenn er dann bei mehreren Units auch mehrmals einkompiliert wird.

Ist eigentlich logisch.
Der Compiler nimmt den Code des Generic als Vorlage und erzeugt on-the-fly neuen Sourcecode wobei der aktuelle Datentyp eingefügt wurde.
Dieser generierte Sourcecode wird natürlich in die Unit eingefügt in der auch das Generic mit dem Datentyp zum ersten Mal aufgetaucht ist.
Zur Laufzeit werden dann noch RTTI Daten erzeugt (bei normalen Klassen geschieht dies zur Compile-time).
Zum Sourcecode des Generics selbst gibt es keinen compilierten Objektcode weil das Generic ja nur eine Schablone ist.

Wenn das Generic + Datentyp(en) nur im Abschnitt implementation auftaucht dann weiss der Linker nicht dass es dieses konkrete Generic schon gibt.
Und so kommt es, dass genau der gleiche Code in mehreren Units stecken kann ohne dass der Linker diese Duplikate zu einem zusammenführen kann.

[jaenicke]

Zitat von stahli:

- Das Freigeben eines Comparers verursacht eine Exception (Eurekalog Prof. kann das aber nicht näher auflösen)

Freigeben? Das ist doch ein Interface. Normalerweise sieht das so aus:

Delphi-Quellcode:

TComparer<Integer>.Construct(function(const ALeft, ARight: Integer): Integer
begin
  Result := ALeft - ARight;
end);

Dann hast du einen IComparer<Integer>, den du dort nutzen kannst.

Zitat von stahli:

(Darüber hinaus habe ich keine Möglichkeit gefunden, einen zugewiesenen Comparer aus einer Liste wieder zu entfernen.)

Das geht in der Tat nicht. Wenn du das brauchst, solltest du den Comparer nur an Sort übergeben, damit der gar nicht direkt im Objekt liegt.

[jbg]

Zitat von sx2008:

Wenn das Generic + Datentyp(en) nur im Abschnitt implementation auftaucht dann weiss der Linker nicht dass es dieses konkrete Generic schon gibt.
Und so kommt es, dass genau der gleiche Code in mehreren Units stecken kann ohne dass der Linker diese Duplikate zu einem zusammenführen kann.

Der Linker könnte schon den gleichen Code zusammenfassen, indem er nach gleichem Code sucht. Aber Embarcadero möchte das gar nicht, sonst hätte ich das schon längst zu XE2 Zeiten als Linker-Aufsatz bereitgestellt.