Welche Stringtyp in XE2 entspricht dem Stringtyp bei Delphi 7?

[Helmi]

Hallo,

welcher Stringtyp entspricht bei XE2 dem Stringtyp von Delphi 7?

Ich möchte ein Projekt von Delphi 7 auf XE2 portieren, nur brauch ich zwingenst für einen Char nur 1 Byte.
Momentan wird mir das immer mit #0 aufgefüllt.

[himitsu]

AnsiString?

[Bernhard Geyer]

Zitat von himitsu:

AnsiString?

AnsiString bzw. PAnsiChar!

[Insider2004]

Es macht überhaupt keinen Sinn, AnsiString in XE2 zu verwenden, wenn alles andere um dich herum Unicode ist. Irgendwo musst du deine Strings ja mal anzeigen.

[jaenicke]

Zitat von Insider2004:

Es macht überhaupt keinen Sinn, AnsiString in XE2 zu verwenden, wenn alles andere um dich herum Unicode ist.

Doch, an vielen Stellen. Seien es Netzwerkübertragungsprotokolle, DLL-Aufrufe, Dateiformate, ...
Man kann nicht alles einfach auf Unicode umstellen, weil dann z.B. bisherige Schnittstellen oder Dateien nicht mehr nutzbar wären.

Wo es möglich ist, sollte man natürlich schon versuchen Unicodestrings zu verwenden. Aber es geht eben an vielen Stellen nicht sofort.

[himitsu]

Zitat von Insider2004:

Es macht überhaupt keinen Sinn, AnsiString in XE2 zu verwenden, wenn alles andere um dich herum Unicode ist. Irgendwo musst du deine Strings ja mal anzeigen.

und

Zitat:

nur brauch ich zwingenst für einen Char nur 1 Byte.

[Helmi]

Zitat von Insider2004:

Es macht überhaupt keinen Sinn, AnsiString in XE2 zu verwenden, wenn alles andere um dich herum Unicode ist. Irgendwo musst du deine Strings ja mal anzeigen.

In diesem Falle macht es Sinn! - Ich habe ein Tool das Dateien für eine Siemens-Steuerung erstellt.
Jetzt muss ich sehr darauf achten, dass sich die Dateien nicht verändern. Deswegen darf es keinen
Unterschied zwischen D7-erstellten Dateien und XE2-erstellten Dateien geben. Deswegen macht es
auf alle Fälle Sinn keine Unicode-Strings zu verwenden.

[p80286]

Zitat von Insider2004:

Es macht überhaupt keinen Sinn, AnsiString in XE2 zu verwenden, wenn alles andere um dich herum Unicode ist. Irgendwo musst du deine Strings ja mal anzeigen.

Böswilligen Gerüchten zufolge solles noch immer Programme geben, die Unicode nicht verstehen und verarbeiten. Als verfechter der reinen Lehre trete auch ich für die ersatzlose löschung solcher Anachronismen ein.
(zumGlück verlangt das niemand für die 32Bitter)

Gruß
K-H

[himitsu]

Unicode verschwendet Speicher ... schließlich ist es sinnloser Weise doppelt so groß, obwohl wir auch ohne auskommen.

[Robotiker]

Hallo,

Zitat von himitsu:

Unicode verschwendet Speicher

genauso kann man argumentieren, dass Ansi-Programme Rechenleistung verschwenden, wenn bei jedem Zugriff auf das Betriebssystem hin- und hergewandelt wird.

Zitat von himitsu:

schließlich ist es sinnloser Weise doppelt so groß, obwohl wir auch ohne auskommen.

Kommt drauf an, wie man "wir" definiert.

Zitat von Helmi:

Ich habe ein Tool das Dateien für eine Siemens-Steuerung erstellt.
Jetzt muss ich sehr darauf achten, dass sich die Dateien nicht verändern.

Der Industriebereich ist ein Anwendungsgebiet, wo man noch lange Zeit mit Ansi-Strings arbeiten wird. Bei komplexeren Anwendungen wird man da nicht umhinkommen, mit unterschiedlichen Stringtypen in einem Programm zu arbeiten. Bei meinen C++ Builder-Programmen halte ich es sogar so, dass ich für die externen Stringformate ISO-C++ Typen wie std::string verwende. Das hat nicht nur den Vorteil, dass dieser Code mit anderen Compilern und Nicht-VCL-GUIs läuft, es macht auch die ganzen Stringumwandlungen deutlicher. Man kann dann besser Grenzen für die Umwandlungen finden, die überflüssige Umwandlungen verhindern.

Einen Schalter zum Umschalten des Stringtyps gibt es unter Delphi/C++ Builder nicht. MS hat das ja in VC++ so gemacht, das ist aber auch nicht der Weisheit letzter Schluss. Man handelt sich damit so tolle Konstruktionen ein wie XCHAR (der Defaultzeichentyp des Programms) und YCHAR (der entgegengesetzte Typ), damit man Code schreiben kann, der in beiden Schalterstellungen funktioniert.

Wünsche noch schöne Rest-Weihnachten

Robotiker