PChar, PAnsiChar, PWideChar, Integer, LPARAM, ... ?

[Glados]

In einem anderen Thema wurde darüber diskutiert, ob man lieber LPARAM() oder Integer() nutzt als letzten Parameter bei SendMessage.
Es wurde aber angedeutet, dass LPARAM richtig sei.

Ich frage mich jetzt aber: was ist wirklich richtig? Herr Puff (Moderator hier im Forum) hat damals selber Integer() genutzt.
http://www.delphipraxis.net/110825-f...n-dateien.html

Außerdem: PChar, PAnsiChar, PWideChar? Was wann?
Im oben genannten beispiel steht

Delphi-Quellcode:

Integer(PChar(

. Partname ist ein string. Ist das heute noch richtig (Delphi 10 Starter)

Dazu lese ich im Netz

Zitat:

Hinweis: PChar ist unsicher, wenn er in Kombination mit normalen string-Werten verwendet wird. PChar unterliegt nicht der Referenzzählung und wird beim Zuweisen nicht kopiert ("Copy-On-Written-Semantik"). Dies kann zur Beschädigung der string-Werte oder zu Speicherlecks führen.

Implizieren die damit, dass man PWideChar nehmen soll?

[EWeiss]

Lese doch meinen vorherigen Post.
LPARAM ist Integer unter 32BIT warum jetzt dafür einen neuen Thread aufmachen?

Delphi-Quellcode:

LPARAM = INT_PTR;
INT_PTR = Integer;

PChar wird automatisch nach PWideChar gekastet kann aber nicht sagen ab welcher Delphi Version.

Ich gehe immer danach wenn keine Warnung oder Fehler seitens des Compiler kommt dann ist es schon richtig.

gruss

[Zacherl]

Zu

Delphi-Quellcode:

LPARAM

ist alles gesagt. Im Grunde IMMER den korrekten Typen aus dem Funktionsprototyp verwenden, dann ist man auf der sicheren Seite.

Delphi-Quellcode:

PChar = PWideChar

bei Unicode Delphi Versionen und

Delphi-Quellcode:

PChar = PAnsiChar

bei älteren nicht-Unicode Delphi Versionen. Referenzzählung hast du hier in keinem Falle.

Zitat:

Zitat von Glados (Beitrag 1385157)

Implizieren die damit, dass man PWideChar nehmen soll?

Eher, dass du

Delphi-Quellcode:

String

verwenden sollst.

[Glados]

Zitat:

PChar wird automatisch nach PWideChar

Heißt das ich kann ohne Probleme alle PChar durch PWideChar ersetzen?

Zitat:

PChar = PWideChar bei Unicode Delphi Versionen und PChar = PAnsiChar bei älteren nicht-Unicode Delphi Versionen.

Diese Information war gut.
Gilt das für alles wo Wide und Ansi drin steht?

Zitat:

Referenzzählung hast du hier in keinem Falle.

Kenne ich nicht, brauche ich nicht :stupid:

[EWeiss]

Zitat:

Zitat von Glados (Beitrag 1385160)

Zitat:

PChar wird automatisch nach PWideChar

Heißt das ich kann ohne Probleme alle PChar durch PWideChar ersetzen?

Zitat:

PChar = PWideChar bei Unicode Delphi Versionen und PChar = PAnsiChar bei älteren nicht-Unicode Delphi Versionen.

Diese Information war gut.
Gilt das für alles wo Wide und Ansi drin steht?

Zitat:

Referenzzählung hast du hier in keinem Falle.

Kenne ich nicht, brauche ich nicht :stupid:

Das macht Delphi selbst der Einfachheit halber.
Damit du wenn du portierst das nicht alles von Hand selbst erledigen musst.

Hatte ich doch geschrieben.

Zitat:

Eher, dass du String verwenden sollst.

Ist mir neu den viele Funktionen erwarten nun mal PWideChar und nicht string.


gruss

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1385160)

Zitat:

PChar wird automatisch nach PWideChar

Heißt das ich kann ohne Probleme alle PChar durch PWideChar ersetzen?

Wenn du sicher bist, dass dein Code nie auf einer Ansi-Version von Delphi kompiliert werden wird, ja. Würde die explizite Verwendung von

Delphi-Quellcode:

PWideChar

bzw.

Delphi-Quellcode:

PAnsiChar

aber tatsächlich nur dann empfehlen, wenn du eine Funktion oder API hast, die ebenfalls diesen expliziten Typen erwartet.

Delphi definiert bei WinAPIs auch in der Regel z.b.

Delphi-Quellcode:

MessageBoxA

,

Delphi-Quellcode:

MessageBoxW

und dann einmal noch nur

Delphi-Quellcode:

MessageBox

, welches dann auf eine der beiden Varianten verweist. Dadurch brauchst du dir über A/W keine Gedanken machen und einfach

Delphi-Quellcode:

MessageBox(PChar(), ...)

aufrufen. Willst du in irgendeinem Falle mal eine explizite Version, dann solltest du auch den Typen in die explizite Form casten:

Delphi-Quellcode:

MessageBoxA(PAnsiChar(), ...)

.

[Glados]

Zitat:

Wenn du sicher bist, dass dein Code nie auf einer Ansi-Version von Delphi kompiliert werden wird, ja

Warum sollte man eine 10 jahre alte Delphi-Version verwenden?

Ich hab hier zum Beispiel

Delphi-Quellcode:

:= GetFileAttributes(PWideChar(

.
Erwartet wird hier tatsächlich Winapi.Windows.LPCWSTR. Hier besser als auf LPCWSTR casten?

[himitsu]

Zitat:

Warum sollte man eine 10 jahre alte Delphi-Version verwenden?

Weil es nicht nur Delphi gibt?

z.B. FreePascal und Lazarus (die bekannteste IDE und GUI-Framework dafür)
Da hat man sich zu großen Teilen für UTF-8 entschieden, als man auf Unicode umstellte, während Delphi sich an der WinAPI orientiert, also UTF-16 (seit WinXP) und UCS-2 (Win2K).

Zitat:

Zitat von Glados (Beitrag 1385154)

Habe selbe Zeile auch schon mit DWORD gesehen.
Hier wird u.a. auch Integer verwendet http://www.cryer.co.uk/brian/delphi/...eforfolder.htm

DWORD ist noch falscher, als Integer.

Die Parameter von SendMessage sind Systemabhängig, also unter 64 Bit sind sie ebenfalls 64 Bit.

DWORD ist immer nur 4 Byte.
Integer/Cardinal waren mal Systemtypen > in Windows 3.1 16 Bit waren sie ebenfalls 16 Bit, aber bei der Entwiclung zu 64 Bit hatten sich die großen Entscheider entschiden den Integer einzufrieren und einen neuen Typ zu erfinden. In Delphi nennen sie sich NativeInt und NativeUInt.

Vergleichbar Char, PChar und String, welche sich anpassen.
AnsiString, AnsiChar PAnsiChar usw. sind immer fest definiert.

Passend zu diesen Typen gibt es auch sich selbt anpassende Funktionen.
z.B. CreateFile (PChar) und CreateFileA (PAnsiChar) oder CreateFileW (PWideChar).

Vorallem in der WinAPI hat eine API-Funktion auch genau eine Parameterdefinition, je Systemkonfiguration (ANSI/Unicode + 32/64 Bit).
Es gibt die beiden ANSI- und Unicode-Versionen und einen Alias, der auf das aktuell hauptsächlich unterstützte System verweist.


Also erstmal kommt die Entscheidung ob der geschriebene Code statisch oder dynamisch ist.
> ist er immer nur ANSI oder Unicode (bzw. 32 oder 64 Bit)
> oder passt er sich ans System an

Dementsprechend muß man dann auch die passenden Typen und Funktionen verwenden (statisch oder dynamisch).
Bei der Vermischung von statisch und dynamisch kommt es zu problemen, wenn das System sich ändert, da sich dann ein Teil ans system anpasst und der Andere bleibt unverändert.

[Glados]

Statisch? Dynamisch? Jetzt bin ich voll hinterm Berg. Ich bin ein ganz normaler Noob der Delphi privat nutzt.

Habe eben einfach alle PChar durch PWideChar ausgetauscht. Das war nämlich auch was, was die Funktionen alle erwartet haben.
PChar ist wie ich verstanden habe zwar auch PWideChar, aber ich nehme lieber PWideChar da ich eh nicht auf ein älteres Delphi zurück gehe.

[EWeiss]

Zitat:

aber ich nehme lieber PWideChar da ich eh nicht auf ein älteres Delphi zurück gehe.

Da machste nix falsch.


gruss