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:

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:

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:

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:

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... :roll:

Zitat:

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:

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.

[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 :stupid:

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 :mrgreen:

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

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:

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:

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:

Zitat von jbg

Zitat:

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:

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

[nicodex]

Zitat:

Zitat von Oreaden

Das Coole an dem Integer oder int ist doch, dass er

• als Pointer verwendet werden kann
  [...]

Dafür gibt es in C intptr_t/uintptr_t/ptrdiff_t (ISO/IEC 9899:1999) und in FreePascal PtrInt/PtrUInt.
Für Delphi hätte man hoffen können, dass Cardinal (als einziger bereits existierender Typ, der ansatzweise in Frage kommt) auf 64-bit vergrößert wird, damit der Portierungsaufwand nicht so hoch wird... allerdings sieht es nicht danach aus und jeder Komponentenhersteler wird sich für ältere Delphi-Versionen seinen eigenen Ptr(U)Int definieren dürfen. Spätestens bei der Portierung auf 64-Bit wird den Delphi-Entwicklern die bisherige THandle-Definition und -verwendung auf die Füße fallen (Handles sind Pointer, kein Ordinaltyp). Es ist also davon auszugehen, dass bisheriger Delphi-Quellcode relativ oft aufwändig portiert oder neu entwickelt werden muss...

[jbg]

Zitat:

Zitat von nicodex

oder neu entwickelt werden muss...

Wir wollen den Teufel mal nicht an die Wand malen. Ich denke, dass der Compiler um ein paar Warnungen erweitert wird, mit denen er "Integer(Pointer)" abfängt.

[Chemiker]

Hallo,

ihr macht mir ja Freude.
Sollte man bei neuen Projekten dazu übergehen eine Unit mit eigenen Typen anzulegen, damit man sie später einfacher konvertieren kann?

Bis bald Chemiker

[jbg]

Zitat:

Zitat von Chemiker

Sollte man bei neuen Projekten dazu übergehen eine Unit mit eigenen Typen anzulegen, damit man sie später einfacher konvertieren kann?

DWORD_PTR, INT_PTR, LONG_PTR, ... sind seit Delphi 2007 dabei
NativeInt/NativeUInt ist seit Delphi 2009 (offiziell) dabei.

[Oreaden]

Zitat:

Zitat von Chemiker

Hallo,

ihr macht mir ja Freude.
Sollte man bei neuen Projekten dazu übergehen eine Unit mit eigenen Typen anzulegen, damit man sie später einfacher konvertieren kann?

Bis bald Chemiker

Guten Abend Chemiker,

an Deiner Stelle würde ich mir keine allzugroßen Gedanken darüber machen. Der Prozessor und die Architekturen werden bislang noch nicht von Microsoft definiert. Sollte dies jedoch der Fall sein, wird es Zeit auf ein Betriebssystem zu wechseln, welche die aktuellen Anforderungen erfüllen kann.

Wünsche noch einen schönen sorgenfreien Abend
Oreaden

[himitsu]

Zitat:

Zitat von jbg

NativeInt/NativeUInt ist seit Delphi 2009 (offiziell) dabei.

Und Inoffiziell gibt's die schon lange (soweit ich weiß seit D5) :angel2:

Zitat:

Zitat von jbg

Ich denke, dass der Compiler um ein paar Warnungen erweitert wird, mit denen er "Integer(Pointer)" abfängt.

Wenn deren Größe nicht übereinstimmt, dann sollte der Compiler sowieso meckern. (macht er jetzt ja auch schon)

[Bernhard Geyer]

Zitat:

Zitat von Oreaden

Das Coole an dem Integer oder int ist doch, dass er

• als Pointer verwendet werden kann

Igiit. Sowas kenn ich primär aus dem C/C++ Lager wenn möglich unleserlicher und schlecht wartbarer Code erzeugt wird. Im Delphi-Umfeld ist so ein mißbrauch eher ein Zeichen entweder von mangelden Fähigkeiten oder von Faulheit.

Zitat:

Zitat von Oreaden

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

Deshalt ist auch auf modernen CPUs ein Alignment von 64 Optimal. Und das unabhängig von 32-Bit oder 64-Bit Programmen.
Und bei "normalen" Programmen wird sich die Integerarithmetik nur in sehr geringen maße auf die Performance auswirken (Normal = Kein Number-Crunsher-Aufgaben oder Bildbearbeitung)