Migration Delphi 6 > Delphi 2010 bzgl. Unicode

[Frederika]

Wie kann man die Unicode-Unterstützung abschalten? Vielleicht eine Compileroption?

Ich habe mannigfaltige Datenformat-Strukturen, die allesamt byte-genau arbeiten müssen. Wie löst man das am besten?

[himitsu]

Zitat von Frederika:

Wie kann man die Unicode-Unterstützung abschalten? Vielleicht eine Compileroption?

Direkt ist sowas nicht möglich, aber es gibt da wohl irgendwas nicht ganz Offizielles, welches angeblich teilweise funktionieren soll
Unicode 2009 abschalten

Zitat von Frederika:

Wie löst man das am besten?

Indem du die Strukturen anpaßt?

Char > AnsiChar
String > AnsiString
usw.

bei sowas würde ich auch direkt bei der Erstellung die Records als PACKED definieren, damit mir die Speicherausrichtung nicht mal alles kaputt macht.

http://www.delphipraxis.net/internal...=record+packed

[Frederika]

Das ist ja megadumm gelöst von Delphi, sorry, aber wirklich. Man muss jetzt alle Char in AnsiChar wechseln? Und "String" wird zu "AnsiString"? Hätte man ja andersherum abwärtskompatibel lösen können, oder? Was bedeutet "usw."? Welche Typen muss ich noch bedenken bei der Migration? Die Delphihilfe ist da extrem mager.

Kann man die Ersetzung einfach automatisch durchführen und dann passt es? Wäre ja immerhin nicht so schwierig.

Muss man sonst noch Fallen bzgl. Unicode beachten?

(Packed ist ohnehin alles und SizeOf(MyStruct) muss natürlich auch exakt passen)

[himitsu]

Delphi 2009 ist nunmal Unicode ... da ist das halt normal
(dumm sind nur andere Dinge gelöst ... viele Funktionen, wie AnsiUpperCase sind auch Unicode, obwohl sie nach Ansi klingen ... das soll laut CodeGear allerdings die Migration erleichtern, weil man diese Funktionen nicht extra umbennen muß, aber diese Namensgebung ist einfach nur scheiße )


Integer, String, Char sind halt Systemspezifische Typen ... diese waren schon immer (seit Delphi 2) so ausgelegt
Heißt, sie passen sich immer an das System an, für welchen der Compiler ausgelegt ist

AnsiString ist immer ANSI
WideString (und seit D2009 auch UnicodeString) sind immer Unicode

Integer = 32 Bit in einem 32 Bit System
und wenn Delphi mal 64 Bit kann, dann ist Integer eben 8 Byte / 64 Bit groß.

Zitat:

Kann man die Ersetzung einfach automatisch durchführen und dann passt es?

du kannst mal schauen, was dieses Refactoring alles kann ... nutze es zwar nie, aber theoretisch müßte es da Hilfreich sein

[mkinzler]

In den meisten Fällen bei sauberen Code, wenn nicht von einer festen Zeichenlänge von einem Byte ausgegangen wird anstatt diese zu ermittlen oder Funktionen verwendet werden, welche AnsiString erwarten, kann man auch String stehen lassen. Dies ist auch der zu bevorzugende Weg. Falls das nicht funktioniert sollte man versuchen die Ursache zu finden und zu beheben.

[jbg]

Zitat von himitsu:

Integer = 32 Bit in einem 32 Bit System
und wenn Delphi mal 64 Bit kann, dann ist Integer eben 8 Byte / 64 Bit groß.

Da CodeGear bis jetzt sich der Windows Platform angepasst hat, gehe ich davon aus (und habe auch schon entsprechendes gelesen), dass sie Microsoft folgen und das abstrakte Datenmodel LLP64 nutzen, das auch von der Win64 API eingesetzt wird.

Somit bleibt Integer ein 32 Bit Datentyp.

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.

[himitsu]

was'n das jetzt wieder

dann sieht es ja mit Codes ala Interger(Pointer) voll Scheiße aus

[mkinzler]

Man muss doch jedes Problemfeld (Fettnäpfchen) mitnehmen

[Chemiker]

Hallo,

dann kann man sich ja fast überlegen, ob man sich nicht seinen eigenen Datentyp für integer anlegt und diesen bei der Einführung vom 64 Bit-Delphi nur umstellt.

Bis bald Chemiker

[himitsu]

du meinst also so wie mein TWideString (für WideString oder UnicodeString) ... ist zwar 'ne Lösung, aber macht es nicht immer leichter 'nen Code zu verstehen, wenn jetzt überall eigene/eigenwillige Typen rumschwirren