String in BDS 2006 = AnsiString in RAD 2009?

[Chemiker]

Hallo,

ist vielleicht eine blöde Frage, aber ist
String in BDS 2006 gleich AnsiString in Rad 2009?

Oder, gibt es da einen Unterschied?

Bis bald Chemiker

[mkinzler]

Jein, in Delphi vor D2009 ist String ein "virtueller" Typ der je nach Inhalt/Einstellung entweder ein klassischer Pascalstring ( ShortString) oder ein AnsiString ist. In d2009 ist String mit UnicodeString gleichzusetzen und die beiden anderen Typen müssen explizit deklariert werden.

[Chemiker]

Hallo mkinzler,

ich frage, wegen den EndString und StartString im AdPacket von AsyncPro die scheinen nicht mehr richtig erkannt zu werden. Normaler weise gebe ich dort immer #2 ein für STX und #3 für ETX ein, aber diese werden nicht mehr erkannt und deshalb wird kein OnStringPacket-Event mehr ausgelöst.

Bis bald Chemiker

[jbg]

Zitat von mkinzler:

ein "virtueller" Typ der je nach Inhalt/Einstellung

Spielst du hier auf {$H+/-} an? Ja, es gibt (hirnamputierte) Leute, die den tatsächlich einsetzen. Ansonsten ist string[255] auch unter Delphi 2009 noch ein ShortString(=PascalString) bei dem 1 Zeichen gleich 1 Byte ist.

D2007-string = D2007-AnsiString = D2009-AnsiString <> D2009-string = D2009-UnicodeString

Wobei man mit AnsiString unter Delphi 2009 aufpassen muss. So gibt es z.B. zwar die Pos-Funktion auch für diese, nur nutzt der Compiler lieber die Unicode-Version. Der Compiler wandelt also den AnsiString zuerst in einen UnicodeString um, sucht nach dem Sub-String und liefert die Unicode-Position zurück, die sich von der Ansi-Postition unterscheiden kann. Da können schöne Zugriffsverletzungen entstehen. Also besser den Code nicht "ansifizieren" sondern lieber auf Unicode umstellen, da das einiges an Kopfschmerzen verhindert und man nebenbei all die Schlampereien und den Missbrauch von AnsiStrings als Byte-Array bereinigt.

[Lasse2002]

Wobei man allerdings darauf verzichten sollte, in Delphi 2009 generell alle Strings nach AnsiStrings umzuändern. Einen AnsiString sollte man nur dort verwenden, wo man auch in D1-D2007 einen AnsiString hätte verwenden sollen.

AsyncPro ist ein typischer Fall wo AnsiStrings benötigt werden, da die Protokolle meist auf ANSI-Daten aufbauen. Es kann gut sein, daß ich in meiner Delphi 2009 Konvertierung von AsyncPro noch ein paar Dinge übersehen habe. Da steckt insgesamt schon viel Arbeit dahinter, weil bei TurboPower häufig AnsiString für Dinge verwendet worden sind, die eigentlich ein normaler String hätten sein sollen, und umgekehrt.

[Chemiker]

Hallo,

@jbg: nein, den Compiler-Schalter setze ich nicht ein, es geht um eine ältere Komponente(AsynPro). Wo ein string in einem AnsiString geändert worden ist, die Komponente aber sich nicht gleich wie mit einem alten String verhält.
Aber die Informationen sind schon sehr interessant.

@Lasse2002: Du hast die Konvertierung auf D 2009 vorgenommen? Sind die Komponenten getestet, oder sind die String und Char mit Suchen und Ersetzen in AnsiString und AnsiChar geändert worden?

Ein Fehler hatte ich schon gefunden und zwar können sie nicht compiliert und installiert werden, weil in der Unit: AdFaxCvt in der USES – Anweisung: Windowsm steht. Das m muss durch ein Komma ersetzt werden.

Zitat von Lasse2002:

Da steckt insgesamt schon viel Arbeit dahinter, weil bei TurboPower häufig AnsiString für Dinge verwendet worden sind, die eigentlich ein normaler String hätten sein sollen, und umgekehrt.

Das kann ich mir gut vorstellen.

Wenn ich den Fehler finde und in beseitige, bis Du an dem Ergebnis interessiert?

Bis bald Chemiker

[Lasse2002]

Zitat von Chemiker:

@Lasse2002: Du hast die Konvertierung auf D 2009 vorgenommen? Sind die Komponenten getestet, oder sind die String und Char mit Suchen und Ersetzen in AnsiString und AnsiChar geändert worden?

Ja, die Konvertierung stammt von mir. Auf ein globales Suchen und Ersetzen hab ich verzichtet, weil die Ergebnisse dann nur sehr bescheiden sind, falls es überhaupt compiliert. Ich hab versucht, nach Möglichkeit immer den richtigen String-Typ einzusetzen. Wobei diese Entscheidung nicht immer leicht ist. Bei AsyncPro hab ich im Zweifelsfall den AnsiString bevorzugt, weil die Protokolle meist ANSI Daten enthalten. Dahingegen darf ein String für einen Dateinamen kein AnsiString sein. Ich hab nicht sehr viel getestet, das wichtigste war erstmal, daß es compiliert.

Zitat von Chemiker:

Ein Fehler hatte ich schon gefunden und zwar können sie nicht compiliert und installiert werden, weil in der Unit: AdFaxCvt in der USES – Anweisung: Windowsm steht. Das m muss durch ein Komma ersetzt werden.

Tatsache. Ich frage mich, wie das bei mir kompiliert hat...

Zitat von Chemiker:

Wenn ich den Fehler finde und in beseitige, bis Du an dem Ergebnis interessiert?

Natürlich. Du kannst auch nochmal die aktuelle Version herunterladen, ich habe gerade noch einen Fehler beseitigt.
http://www.songbeamer.com/delphi/

[richard_boderich]

@jbg

Zitat:
Spielst du hier auf {$H+/-} an? Ja, es gibt (hirnamputierte) Leute, die den tatsächlich einsetzen. Ansonsten ist string[255]
Zitat Ende

Könntest du bitte auch erläutern was es mit dem Compilerschalter auf sich hat? Und mir wurde eingetrichtert, das ich solche
Deklarationen (String[zahl]) im Hinblick auf die Sicherheit tunlichst unterlassen sollte!? Trotz NoExecute, NX und DEP dürfte
sich doch daran nichts geändert haben, oder doch?

[Chemiker]

Hallo richard_boderich,

Zitat von Delphi-Hilfe:

In Win32 können Sie die Direktive {$H-} verwenden, wenn string als ShortString interpretiert werden soll.

Ob die Short-Strings jetzt unsicher sind, konnte ich bis her nicht feststellen. Allerdings muss ich sagen, dass in älteren Routinen diese bei mir sehr häufig verwendet habe. Sie sind in den meisten Fällen in einer Konstanten-Unit und sind dadurch relativ pflegearm.

Bis bald Chemiker

[mkinzler]

Zitat:

So gibt es z.B. zwar die Pos-Funktion auch für diese, nur nutzt der Compiler lieber die Unicode-Version.

Die Chr()-Funktion hat auch massive Probleme. So ganz ausgegoren ist die "neue" Stringbehandlung von D2009 alos noch nicht. Einserseits scheuen sie alte Zöpfe wie die BDE abzuschneiden, auf der anderen Seite sorgen sie schlagartig für Kompatibilitätsprobelmen, mit welchem auch Fremdkomponentenhersteller kämpfen.