RAD Studio XE7: Was Entwickler davon halten...

[p80286]

Zitat von himitsu:

Wo kommen eigentlich diese Aussagen her?

Und warum sagt Gerhard Stoltz in der eMail was komplett anderes, als auf der Webseite? (abgesehn von deutsch in der Mail und englisch auf der Webseite)

Du wirst schon wissen was Du meinst.

Zitat von himitsu:

Nachteil: Beim Unicodeumstieg muß aufgepasst werden (OK, eigentlich nicht so sehr, wenn man früher alles richtig gemacht hatte)

Was heißt hier "richtig"? Wichtig ist doch vielmehr wofür man Char/String eingesetzt hat. Solange man es nur mit Buchstaben und Text zu tun hat, ist man auf der sicheren Seite. Wenn allerdings die Frage auftaucht ob da jetzt ein Char 8 oder 16 Bit groß ist, da wird's dann interessant, und nicht zu vergessen Umlaute, die in der Darstellung nur ein Zeichen groß sind, deren Codierung aber mehrere Bytes umfasst, da muß man dann manchmal mitdenken.

Gruß
K-H

[himitsu]

richtig:

Wenn das immer ANSI sein mußte, dann auch als ANSI deklariert (vorallem bei Schnittstellen und Speicher-/Transferdaten).
Da wo es "egal" war, die Alias Char/PChar/String verwendet.
Und zusammengehöriges auch richtig deklariert, wie z.B. CreateFile > PChar/String und CreateFileA > PAnsiChar/AnsiString.

So wie man es schon vom Alias "Integer" her schon kannte, der in Delphi 1 noch 16 Bit war. (OK, daß man auf die Idee kommt den Integer bei 64 Bit auf 32 Bit einzufrieren und dafür einen Neuen zu erfinden, konnte keiner ahnen)
String und PChar waren ja schon per Definition schon länger als veränderlich definiert,
auch wenn Delphi über 10 Jahre brauchte, bis es sich dem Unicode-Windows angepasst hatte und noch länger dauerte es bis zum Windows 64.

[p80286]

Da würde ich Dir nicht widersprechen, nur wie erkläre ich einem unbedarften Menschenkind, daß M$ Ansi,(Oem),UTF8 und Unicode fröhlich durcheinander würfelt (*.doc Word 2003). Da sind Deine "richtigen" Arbeitsweisen dann nur noch Richtlinien wie man tunlichst programmieren sollte, damit die Fehlerhäufigkeit nicht so hoch ist, und vor allem, wenn dann mal ein Fehler auftaucht, er schneller zu finden ist.

Was die Integers angeht,Da nutz ich (wo immer es geht) Int16,Int32,Int64 bzw. Word16,Word32,Word64.

Gruß
K-H

[himitsu]

Was gerne gemacht wurde, was Pointer/Object <-> Integer, welches ja funktionieren würde, wenn der INT/Integer mit wachsen würde.

Bei SendMessage nutzte ich sowieso gerne die Original-Typen (LPARAM, WPARAM und LRESULT), womit ich dort fast keine Probleme hatte.
Aber ansonsten ist der Typ IntPtr in Delphi halt nicht so geläufig, denn der wäre für solche Cast der Richtigere. (neben NativeInt/NativeUInt jetzt und Integer/Cardinal früher)