Nun bringen wir Generics ins Spiel:

1. var
2. anAnimal: TAnimal;
3. newAnimals: TObjectList<TAnimal>;
4. begin
5. newAnimals := TObjectList<TAnimal>.Create(true);
6. newAnimals.Add( TAnimal.Create );
7. newAnimals.Add( TDog.Create );
8. newAnimals.Add( TCat.Create );

Wir typisieren die Elemente der TObjectList<>-Klasse (wichtig: diese TObjectList ist nun die generische Variante aus Generics.Collections.pas, die Version in Contnrs.pas ist weiterhin nicht-generisch.) direkt auf Objekte, die von TAnimal abstammen müssen. Dies geschieht mithilfe einer generischen Variablendeklaration, die nach dem eigentlichen Klassennamen in Klammern der Form „<“ und „>“ erfolgt. D.h. in dem obigen Beispiel definieren wir eine Variable namens newAnimals der Klasse TObjectList. Damit Delphi damit etwas anfangen kann, noch die beiden Units Generics.Defaults und Generics.Collections in die Uses-Klausel aufnehmen. In newAnimals können wir nun nur Objekte ablegen, die von TAnimal abstammen.

1. newAnimals.Add( TAnimal.Create );
2. newAnimals.Add( THuman.Create );

Was passiert nun bei dem Versuch, eine Instanz von THuman auf der Liste abzulegen - bekommt der Anwender eine Exception? Nein: Bereits wir - die Entwickler - bekommen einen Fehler vom Compiler:

1. [DCC Fehler] …(50): E2010 Inkompatible Typen: 'TAnimal' und 'THuman'

Ich denke die Vorteile, die sich durch eine derartige Validierung durch den Compiler ergeben, liegen klar auf der Hand. Delphi 2009 bringt noch zahlreiche weitere Klassen mit, die Generics unterstützen und somit nicht nur den Quellcode sicherer machen, sondern auch besser lesbar.

Selbstverständlich kann man auch eigene generische Klassen definieren, aber das würde den Rahmen dieses Artikels sprengen.

Unicode

von Daniel Magin

Die größte Änderung in Delphi 2009 und C++Builder 2009 ist die komplette Erweiterung in Unicode. CodeGear hat hier mit einem korrekten Konzept die Möglichkeit für den Entwickler geschaffen, seine Anwendung nicht nur multilingual in verschiedenen „Schriften“ darzustellen, sondern auch die komplette Entwicklungsumgebung umgestellt. Dies war früher nur schwierig mit Fremdkomponenten (z.B. TNT) oder API-Tricksereien zu erreichen. Unicode ist ein komplett neuer Ansatz zum bisherigen ASCII Zeichensatz. RadStudio 2009 kann mit den verschiedenen Unicode Standards umgehen, inkl. dem gebräuchlichsten UTF-8. Hier besitzt ein Zeichen nicht etwa ein 8-Bit Code, sondern wird komplett in einer Byte-Kette aufgebaut. Solch' ein Zeichen kann aus 2 oder 3 oder theoretisch auch noch mehr Bytes bestehen.

Die IDE ist in all ihren Bereichen vollkommen Unicode-fähig. Die gesamte IDE ist nun eine Unicode-basierte Anwendung, was erfordert, dass alle Komponenten und der gesamte Quellcode bei der Entwicklung auch auf dem Typ UnicodeString basieren. Unicode-Zeichen werden von Bezeichnern und Strings vollständig unterstützt. Die Änderung des Standard-Stringtyps wirkt sich auch auf andere Datentypen und viele Funktionen aus. Zum Beispiel ist SizeOf(Char) jetzt 2 Byte groß, nicht mehr 1 Byte. Aufrufe von Length(MyString) geben die Anzahl der Zeichen, nicht die Anzahl der Bytes in dem String zurück.

Abb. 3: Unicode-Unterstützung in Delphi 2009

Eine Umstellung von bestehenden Entwicklungen in Unicode-fähige Anwendungen kann nun recht einfach erfolgen. Die kompletten VCL-Komponenten wie Button, Grid, Listbox, Combobox usw. können ab sofort mit Unicode umgehen und darstellen. Auch die Ableitungen, wie ganzen DB-Komponenten erben somit auch diese Funktionalität. Sollten Sie aber in Ihren Datenbank-Anwendungen auch mit Unicode arbeiten wollen, vergessen Sie nicht, auch die Datenbank selbst auf Unicode umzustellen und den Connectionstring ihrer DB-Zugriffskomponente auf den entsprechenden Charset einzustellen. Wer auf CodeGear‘s DBXpress oder IBX setzt, kann sich gelassen zurücklehnen, da diese nun auch komplett mit Unicode-Unterstützung erweitert wurden und die Umstellung daher recht einfach ist. Sie finden ein einfaches Beispiel mit DBXpress und Interbase auch auf meinem Blog unter: http://dmagin.wordpress.com/2008/07/17/tiburon-vcl-db-unicode-application-with-interbase-2007/.

Sollten Sie ein „altes“ Projekt in der neuen Version 2009 öffnen, so wird eine Sicherheitskopie ihres Projektes mit der Meldung angelegt: „Upgrade des Projekts wird ausgeführt. Sicherung .dproj.2007 erstellt.“

Es werden Flags hinzugefügt, damit Sie festlegen können, ob der Standard-String-Typ ein UnicodeString oder ein AnsiString ist. Damit lässt sich Code beibehalten, der ältere Versionen von Delphi und C++Builder in demselben Quelltext unterstützt. Für den überwiegenden Teil von Quelltext, der Standardoperationen mit Strings durchführt, dürften zwei separate UnicodeString- und AnsiString-Codeabschnitte nicht erforderlich sein. Wenn eine Prozedur jedoch Operationen ausführt, die von der internen Struktur der String-Daten abhängen oder die mit externen Bibliotheken interagieren, könnten separate Codepfade für UnicodeString und AnsiString nötig sein.

In der neuen sehr umfassenden Hilfe (hier wurde von CodeGear endlich viel Arbeit investiert) findet man ein ganzes Kapitel über die Umstellung von ANSI Programmen in Unicode. Ein Blick in diesen Bereich ist sehr zu empfehlen. Auch die Tools rund um die neue Version, wie z.B. DBExplorer, Translationmanager, usw. wurde umgestellt. Gerade auf den letzten EKON-Konferenzen wurde immer wieder von den Teilnehmern insbesondere der Unicode Support für WIN32 in Delphi und C++Builder gefordert. Schön, dass die Entwickler von CodeGear dies erhört haben. Nun dürfte nichts mehr im Wege stehen beim Schreiben von Anwendungen mit Schriften, die man gar nicht versteht - z.B. Klingonisch, welches tatsächlich im Unicode-Zeichenraum enthalten ist. In diesem Sinne: Qapla'!

Holger Flick, Daniel Magin, Olaf Monien und Thomas Pfister sind Autoren des Entwickler Magazins und Sprecher auf der EKON.