Einzelnen Beitrag anzeigen

jbg

Registriert seit: 12. Jun 2002
3.483 Beiträge
 
Delphi 10.1 Berlin Professional
 
#13

Re: String in BDS 2006 = AnsiString in RAD 2009?

  Alt 11. Nov 2008, 12:22
Und das aus guten Gründen. Es mag auf den ersten Blick recht einfach aussehen, einfach die Strings hin- und herzuschalten. Aber auf einen zweiten Blick nimmt das grässliche Ausmaße an. Was ist, wenn Unit A eine Klasse mit einer virtuellen Methode definiert, die einen "string=UnicodeString" Parameter hat. Unit B wird dann mit "string=AnsiString" kompiliert, leitet von der Klasse ab und überschreibt die virtuelle Methode. Der Compiler würde nun eine Typeninkompatiblität anprangern. Gut, denkt man, dann ändere ich die Ableitung einfach in "UnicodeString" ab. Das funktioniert aber nur solange, bis jemand auf die Idee kommt, Unit A mit "string=AnsiString" zu kompilieren. Bei zwei Units mag das sogar noch machbar sein, aber wenn man dann mehrere hundert Units hat, die voneinander abhängen, will ich ganz bestimmt nicht der Entwickler sein, der die Schreiben und Warten muss. Ganz zu schweigen, von der Unleserlichkeit des Codes. Was bedeutet "string" nun in dieser Unit, in diesem Abschnitt, in dieser Zeile.

Das nächste Problem besteht darin, dass die RTL und VCL Unicode sind. Man müsste also um ständiges Konvertieren, was zu String-Zeichen-Index Problemen führt, zu vermeiden, eine RTL und VCL für AnsiString bereitstellen. Am besten noch gemischt. CodeGear wäre da zwar ein wenig beschäftigt und vor allem der (Telefon/Email-)Support würde in der Flut an Anfragen (warum geht dies und das nicht, was ist jetzt wieder los) untergehen. Aber selbst das würde man sicherlich irgendwie in den Griff bekommen. Bleiben also nur noch die ganzen Drittanbieter von Komponenten. Die wären dadurch nämlich auch dazu verdonnert, ihre Package für RTL/VCL Unicode, RTL-Unicode/VCL-AnsiString, RTL-AnsiString/VCL-Unicode, RTL/VCL AnsiString zu kompilieren. Und ich bin mir ganz sicher, dass die dabei entweder drauf gehen, oder sich auf eine Variante "spezialisieren".

Auch betroffen wären die Events die in der DFM verknüpft sind. Der Event-Typ wurde mit "string=UnicodeString" definiert und die Formular-Unit mit "string=AnsiString". Ich wünsche dann viel Spaß beim Suchen nach der Zugriffsverletzung, da die Events zur Laufzeit ohne Typenprüfung zugewiesen werden.

Es gibt da noch ein paar weiter Gründe, die kann man sich aber aus Allen Bauers Blog-Eintrag selbst erlesen.
  Mit Zitat antworten Zitat