String in BDS 2006 = AnsiString in RAD 2009?

[Chemiker]

Hallo mkinzler,

ich hätte gerne einen Compiler-Schalter, wo man selber bestimmen kann was man will.

Bis bald Chemiker

[mkinzler]

Da hat sich CG aber dagegen entschieden

[jbg]

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.

[Chemiker]

Hallo jbg,

natürlich gibt es gute Gründe von CG keinen Compiler-Schalter anzubieten für die String-Verwaltung, nur meine Situation stellt sich wie folgt dar.
Ich setze folgende Komponenten ein

1. AsynPro das durch Freiwillige wie Lasse 2002 umgestellt wird auf die neuen String-Funktionen.
2. FibPlus für diese Komponente liegt noch keine Version für 2009 vor.

Das Bedeutet jetzt für mich, dass ich bei Datenbanken nach wie vor mit der BDS 2006 arbeite und bei der Datenübertragung mit einer RS 232 Schnittstelle feststellen muss das einige Funktionen nicht oder nicht in der gewünschten Form funktionieren.

Mir steht zwar von beiden Komponenten der Quellcode zur Verfügung, aber ich habe erbliche Schwierigkeiten einen Quellcode zu ändern den ich nicht selber geschrieben habe.

Wenn es einen Compiler-Schalter geben würde, dann könnte man so vorgehen, dass man die Strings an einer zentralen Stelle ändert und wenn die Komponenten Delphi 2009 fähig sind einfach rausnimmt und gut ist.

Man ist ja nicht gezwungen den Schalter zu verwenden, aber gerade in der Übergangszeit hätte er doch geholfen.

Bis bald Chemiker

[jfheins]

Dann macht man einfach diesen Compilerswitch an den Anfang der Unit und schon isse D2009 fähig - war ja einfach

Dann geht das Gemecker los, sobald man (in der nächsten Version) den Compilerswitch entfernt. Ist also im Grunde nur eine Verlagerung.

Der Witz ist doch Gerade, dass unter D2009 jetzt alles Unicode ist, und du nicht im Code nachdenken musst "Hmm, wenn der Entwickler den Switch einmsetzt muss ich das machen sonst das, also schnell ein IFDEF ..."

Und wenn du jetzt sagt von wegen "sanfterer Übergang": Das in Unicode ein Buchstabe nicht immer 1 Byte hat, war vorher klar. Dass D2009 Unicode-enabled sein wird, auch. Dass Codestellen, die auf ersters vertrauen, auf zweiterm nicht laufen, war also nur logisch. Zugegeben, es fehlt noch die rote Unterstreichung im Code

Ich kann deinen Ärger aber natürlich nachvollziehen. Aber guck dir mal die WinAPI an, die durften nie so einen Schnitt machen ==> *wuppdi* machen wir einfach von jeder Funktion eine A und eine W Variante

(Ich hab werder Delphi, noch muss ich mich damit rumschlagen, das sind nur meinee 2 cents )

Edit: P.S.: Freu dich schonmal, wenn Integer auch mal 64 bit haben kann Du kannst ja schonmal durchgehen und alle Codestellen markeiren, die annehmen dass sizeof(Integer)=4 oder auf die absurde Idee kommen, man könnte einen Integer nach TColor casten
Btw.: Für diese Fällte sollte dann ein LogInt/LongWord genommen werden, der sollte immer 32 bit sein und bleiben

[Chemiker]

Hallo jfheins,

also ich erfand die Umstellung von 16 Bit nach 32 Bit nicht so schlimm wie jetzt die Umstellung auf UniCode, aber vielleicht bin ich auch mittlerweile einfach zu alt.

Bis bald Chemiker

[jbg]

Zitat von jfheins:

Freu dich schonmal, wenn Integer auch mal 64 bit haben kann

Was ich so gehört/gelesen habe wird der Typ Integer ein Int32 bleiben. Dafür gibt es dann den NativInteger (den es bereits seit Delphi 2007 gibt) und der ist bei 32 Bit Kompilierung Int32 und bei 64 Bit Kompilierung Int64. (Ist aber alles nur Hörensagen)

Was Probleme machen wird ist die Annahme SizeOf(Integer) = SizeOf(Pointer). Wer also einen Pointer in einen Integer Typecastet und dann etwas Pointer-Arithmetik betreibt wird leichte Probleme beim größeren Adressraum bekommen. Dafür hat Microsoft die Typen DWORD_PTR, INT_PTR, LONG_PTR usw. eingeführt. Aber man kann ab Delphi 2009 hierfür ja auch (endlich) PByte benutzen, oder man macht es eben mit PAnsiChar.

[Bernhard Geyer]

Zitat von Chemiker:

also ich erfand die Umstellung von 16 Bit nach 32 Bit nicht so schlimm wie jetzt die Umstellung auf UniCode, aber vielleicht bin ich auch mittlerweile einfach zu alt.

Die Komplexität der existierenden Anwendungen beim Wechsel von 16-Bit auf 32-Bit war bei weiten nicht so groß und vielfältig als beim Wechsel von Ansi auf Widestring und bald dem Wechsel von 32-Bit auf 64-Bit. Und ein Wechsel nach 64-Bit ist ohne ein funktionsfähigen Unicodeport nicht möglich da die Win64-API AFAIK keine ANSI-Version mehr besitzt.

[Oreaden]

Zitat von jbg:

Zitat von jfheins:

Freu dich schonmal, wenn Integer auch mal 64 bit haben kann

Was ich so gehört/gelesen habe wird der Typ Integer ein Int32 bleiben. Dafür gibt es dann den NativInteger (den es bereits seit Delphi 2007 gibt) und der ist bei 32 Bit Kompilierung Int32 und bei 64 Bit Kompilierung Int64. (Ist aber alles nur Hörensagen)

Guten Morgen JBG,

wäre das dann nicht der Todesstoß? Ab diesen Zeitpunkt wäre dann der int <> integer, also eine einfache Portierung oder Verwendung von C/C++ Schnittstellen wäre nicht mehr möglich. Das Coole an dem Integer oder int ist doch, dass er

• als Pointer verwendet werden kann
• genau die Größe hat, mit der die CPU am besten rechnen kann

Bislang überlebte der int jedenfalls die Schritte von B8 --> B16 --> B32. Sollte er jetzt wirklich an B64 den Tod sterben?

Die möglichen Portierungsprobleme, wären wohl der Tod von Delphi. Aber es ist müßsam darüber zu spekulieren, da das Orakel gerde in der Sommerfrische verweilt.

Schöne Grüße
Oreaden

[jbg]

Zitat von Oreaden:

Bislang überlebte der int jedenfalls die Schritte von B8 --> B16 --> B32. Sollte er jetzt wirklich an B64 den Tod sterben?

Das ist er schon laut Microsoft:

Zitat:

[...] These considerations led to the selection of an abstract data model called LLP64 (or P64). In the LLP64 data model, only pointers expand to 64 bits; all other basic data types (integer and long) remain 32 bits in length.
[...] However, ensuring that the data model affects only pointer data types is the first step. The second step is to define a set of new data types that allow developers to automatically size their pointer-related data. This allows data associated with pointers to change size as the pointer size changes from 32 bits to 64 bits. Basic data types remain 32 bits in length, so there is no change in the size of data on the disk

Quelle: http://msdn.microsoft.com/en-us/libr...83(VS.85).aspx