WINAPI und LPWCH, LPCH, LPCWSTR, LPCSTR.... ?!

CStoll

Wenn du dich darum kümmern mußt, solltest du lieber TCHAR[] verwenden - das wird je nach deinen Projekteinstellungen auf den richtigen Datentyp (char oder wchar_t) übersetzt.

@Glühbirne: Ich erinnere mich düster, daß die Auswahl nicht vom System abhängt, sondern von den Projekteinstellungen beim Compilieren. Außerdem hast du noch den Ansi-Zeichensatz unterschlagen.

geeky

Du solltest TCHAR statt wchar_t oder char benutzen
Das wird abhängig davon ob du Unicode aktiviert hast oder nicht automatisch zu wchar_t (bei UNICODE) bzw. char.

Damit kann dir dann quasi (bzgl. der meisten WinAPI-Funktionen) völlig egal sein ob Unicode nun aktiv ist oder nicht.

(Edit: zu langsam ^^)

evilplayground

Danke! Danke! Danke!
TCHAR scheint ja alle Probleme zu erschlagen!

@CStoll: Was meinst du damit, wenn ich mich darum kümmern muss?
Wenn ich WINAPI Funktionen benutzen möchte, muss ich mich wohl oder übel darum kümmern, oder?

CStoll

evilplayground schrieb:

@CStoll: Was meinst du damit, wenn ich mich darum kümmern muss?
Wenn ich WINAPI Funktionen benutzen möchte, muss ich mich wohl oder übel darum kümmern, oder?

Ich denke, genau das wollte ich damit ausdrücken. Bei Strings, die du mit der WinAPI austauschen willst, solltest du grundsätzlich mit TCHAR, LPTSTR und Co. arbeiten.
(was nicht heißt, daß du für interne Verwendung kein char einsetzen darfst - mitunter ist es notwendig, wenn du beim ÜBergang zur WinAPI aufpasst)

evilplayground

CStoll schrieb:

evilplayground schrieb:

@CStoll: Was meinst du damit, wenn ich mich darum kümmern muss?
Wenn ich WINAPI Funktionen benutzen möchte, muss ich mich wohl oder übel darum kümmern, oder?

Ich denke, genau das wollte ich damit ausdrücken. Bei Strings, die du mit der WinAPI austauschen willst, solltest du grundsätzlich mit TCHAR, LPTSTR und Co. arbeiten.
(was nicht heißt, daß du für interne Verwendung kein char einsetzen darfst - mitunter ist es notwendig, wenn du beim ÜBergang zur WinAPI aufpasst)

Alles klar, dann nochmal danke für die ausführlichen Erklärungen
und sry falls ich den ein oder anderen mit Noob-Fragen genervt hab

Wieder einen Schritt weiter auf dem steinigen C++ Pfad..

theta

@Glühbirne:
GetProcAddress(..) ist ein schlechtes Bsp. in diesem Zusammenhang, da es keine A bzw. W Variante gibt, sondern nur die GetProcAddress(..).

theta schrieb:

@Glühbirne:
GetProcAddress(..) ist ein schlechtes Bsp. in diesem Zusammenhang, da es keine A bzw. W Variante gibt, sondern nur die GetProcAddress(..).

Ich meine mich dunkel daran erinnern zu können, in einem meiner Projekte mit GetProcAddress gearbeitet zu haben. Wäre auch kein Wunder, denn der zweite Parameter muss, egal ob Funktionsname oder Ordinalzahl, ein String sein, und davon gibt es nun mal zwei Versionen.

CStoll schrieb:

@Glühbirne: Ich erinnere mich düster, daß die Auswahl nicht vom System abhängt, sondern von den Projekteinstellungen beim Compilieren. Außerdem hast du noch den Ansi-Zeichensatz unterschlagen.

Auch, aber nur, wenn du die Präprozessordirektive UNICODE aktivierst UND das OS auch Unicode unterstützt. Zudem habe ich geschrieben, dass, wenn man explizit eine bestimmte Funktionsversion haben will, entweder A oder W an den Namen anhängen muss.

Und was den ANSI-Zeichensatz angeht, den meinte ich eigentlich mit Multibyte. Schließlich gibt es so viele Codepages einige verwenden 1, andere mehr Byte pro Zeichen. Ich persönlich treffe auf den Begriff ANSI nur, wenn von 1-Byte-Codierungen die Rede ist - aber noch einmal, sicher bin ich nicht 100%-ig.

theta

Glühbirne schrieb:

Ich meine mich dunkel daran erinnern zu können, in einem meiner Projekte mit GetProcAddress gearbeitet zu haben. Wäre auch kein Wunder, denn der zweite Parameter muss, egal ob Funktionsname oder Ordinalzahl, ein String sein, und davon gibt es nun mal zwei Versionen.

Falsch. Es gibt ein Version und die nimmt ein LPCSTR.
Guck in die Header Files, guck in der MSDN Doku, guck in Jeffrey Richters "Advanced Windows" - Advanced Windows | ISBN: 9781572315488

Deshalb schlechtes Bsp. in diesem Zusammenhang.

theta schrieb:

Deshalb schlechtes Bsp. in diesem Zusammenhang.

Verdammt, ich hätte schwören können ... meine Fresse ... ... werd' ich etwa alt?

CStoll

Glühbirne schrieb:

Und was den ANSI-Zeichensatz angeht, den meinte ich eigentlich mit Multibyte. Schließlich gibt es so viele Codepages einige verwenden 1, andere mehr Byte pro Zeichen. Ich persönlich treffe auf den Begriff ANSI nur, wenn von 1-Byte-Codierungen die Rede ist - aber noch einmal, sicher bin ich nicht 100%-ig.

Es gibt drei verschiedene Zeichensätze - ANSI (1 Byte Zeichen), MULTIBYTE (variable Zeichengröße) und UNICODE (2 Byte). Allerdings werden die ersten beiden Varianten beide durch char's abgebildet und von vielen Funktionen identisch behandelt.

Jochen Kalmbach

CStoll schrieb:

Es gibt drei verschiedene Zeichensätze - ANSI (1 Byte Zeichen), MULTIBYTE (variable Zeichengröße) und UNICODE (2 Byte). Allerdings werden die ersten beiden Varianten beide durch char's abgebildet und von vielen Funktionen identisch behandelt.

Wie kommst Du darauf, dass Unicode 2 Byte sind...

Unicode als solches definiert nur Codepoints. Diese gehen bis U+10FFFF
Brauchen also min. 3 Bytes...
Siehe:
http://www.fileformat.info/info/unicode/block/index.htm

I.d.R. wird aber Unicode in einer bestimmten Codierung verwendet. Windows verwendet UTF-16 (ursprünglich UCS2). Viele Unix-Varianten verwenden UTF-8. Beides sind Multibyte-Character-Sets.

Der einzige nicht Multi-Byte-Character-Set ist UTF-32. Hier kann der Unicode-Zeichensatz (bzw. die Codepoints) direkt abgebildet werden.

Das ganze heisst aber nicht, dass z.B. ein "ä" aus nur einem Codepoint bestehen muss... ein "ä" kann auch aus mehreren Codepoints bestehen... somit ist auch ein nicht-MBCS keine Garantie dafür, dass man Zeichen direkt findet, die man sucht... aber das war ja nicht das Thema

CStoll

Jochen Kalmbach schrieb:

CStoll schrieb:

Es gibt drei verschiedene Zeichensätze - ANSI (1 Byte Zeichen), MULTIBYTE (variable Zeichengröße) und UNICODE (2 Byte). Allerdings werden die ersten beiden Varianten beide durch char's abgebildet und von vielen Funktionen identisch behandelt.

Wie kommst Du darauf, dass Unicode 2 Byte sind...

Schlecht geraten und ungenau formuliert (außerdem hat meine Erinnerung für diese Details etwas nachgelassen, seitdem ich micht nicht mehr so oft damit beschäftigen muß).

*Rewind*

Warum braucht man eigentlich überhaupt so viele Datentypen, wenn es zu fast jedem ein Äquivalent gibt? Ich meine irgendwo gelesen zu haben, dass DWORD, LPSTR, LPCSTR, etc. von den C-Programmierern übernommen wurden, aber das kann doch unmöglich die Erklärung dafür sein... Wenn man sich die Definitionen der Datentypen anschaut... das ist doch alles doppelt (und manchmal dreifach) gemoppelt..
Ich meine wozu braucht man PINT wenn's int * bereits gibt?;

[Rewind] schrieb:

Warum braucht man eigentlich überhaupt so viele Datentypen, wenn es zu fast jedem ein Äquivalent gibt? Ich meine irgendwo gelesen zu haben, dass DWORD, LPSTR, LPCSTR, etc. von den C-Programmierern übernommen wurden, aber das kann doch unmöglich die Erklärung dafür sein... Wenn man sich die Definitionen der Datentypen anschaut... das ist doch alles doppelt (und manchmal dreifach) gemoppelt..
Ich meine wozu braucht man PINT wenn's int * bereits gibt?;

Die Frage habe ich mir auch gestellt. Es ist aber nun mal so, dass das meiste noch Überreste aus der 16-Bit-Ära sind, die, um abwärtskompatibilität zu garantieren, drinne sind.

evilplayground

Hallo nochmal,

also auch wenn das jetzt ein bisschen off-topic ist, ich bin seit 2 Jahren als C# Entwickler für Windows-Applikationen tätig und hab auch schon einige Sachen in Java geschrieben. Aber C++ autodidaktisch zu lernen ist echt der absolute Horror.
Ich komm mir vor als hätte ich noch nie was programmiert. Und die msdn-library ist absolut nicht mein Freund. Ich mein die Doku da ist echt ein bisschen für den .... Es gibt so viele Libraries, für viele gleich mehrere, ein paar noch in C geschrieben... was benutz ich wann. (Bspl. <string> und "String.h").
Wie 2 Beiträge über mir schon erwähnt, kommt noch erschwerend hinzu, dass es für jeden Datentyp 2 oder mehr "Bezeichungen" gibt.
Mittlerweile bin ich soweit, dass ich mir wohl ein Buch kaufen werde... Die Grundlagen der Sprache zu lernen war ja kein Problem, aber mit der WINAPI komm ich echt nur schwer voran. Zumindest alles was über WinMain und die Nachrichtenschleife hinausgeht. Im Netz gibts da ja auch nicht wirklich was dazu.

Ach ja, und nochmal zum Thema:
Ich hab jetzt in meinem "Lern"-Projekt versucht, meine strings die ich mit WINAPI-Funktionen austauschen muss, als TCHAR zu definieren.
Wobei ich bei den einfachsten Sachen wieder auf Probleme stoße.
Bspl. Ich definiere eine variable TCHAR* path und lass mir diese über GetModuleFileName(..) füllen. Funktioniert auch wunderbar. Jetzt würd ich path aber noch gerne abändern mit ein paar Funktionen aus der "String.h" strcpy und so... Jetzt erwarten diese aber wieder eine variable vom Typ char*...

So, Noobfrage: Ich denke hier muss ich wohl casten, oder?
Wenn ja, wie?

Danke an alle die sich meinen kleinen Erguss hier durchlesen und
vll noch Ihren Senf dazugeben!

*Rewind*

evilplayground schrieb:

Hallo nochmal,
Mittlerweile bin ich soweit, dass ich mir wohl ein Buch kaufen werde... Die Grundlagen der Sprache zu lernen war ja kein Problem, aber mit der WINAPI komm ich echt nur schwer voran. Zumindest alles was über WinMain und die Nachrichtenschleife hinausgeht. Im Netz gibts da ja auch nicht wirklich was dazu.

Ach ja, und nochmal zum Thema:
Ich hab jetzt in meinem "Lern"-Projekt versucht, meine strings die ich mit WINAPI-Funktionen austauschen muss, als TCHAR zu definieren.
Wobei ich bei den einfachsten Sachen wieder auf Probleme stoße.

Da sag ich nur: geht mir genau so!
Nun zu deinem kleinen Problem. Von String zu char* kannst du auch so casten (dürfte aber nicht allzu schwer zu finden sein...):

string sMyStr;
char* cCharArray= new char[sMyStr.size() + 1];

//dann Inhalt mit strcpy() übergeben
strcpy(m_cCharArray, sMyStr.c_str(), sMyStr.size());

Rewind

theta

Ich habe vor längerem mal Hilfsklassen gemacht, welche das Konvertieren von Unicode nach Multibyte und umgekehrt übernehmen:

Oberster Post von mir (StringUtil.h und cpp):
http://www.c-plusplus.net/forum/260205-10

Hier noch einige Hinweise:
Erster Post von mir:
http://www.c-plusplus.net/forum/276277

Falls die Benutzung unklar ist, bitte hier nachfragen.

evilplayground

Danke Rewind,

Sehr schön! Mittlerweile seh ich den Wald vor lauter Bäumen nicht mehr.
Ich glaub ich sollte mal ne Pause machen

@theta:
Ich werd mir das bei Gelegenheit zu Gemüte führen,
aber danke schon mal dafür! Ich denk die werden mir sicher gute Dienste leisten.

evilplayground

evilplayground schrieb:

So, Noobfrage: Ich denke hier muss ich wohl casten, oder?
Wenn ja, wie?

Casten? Ist keine Noob-Frage.

Von Multibyte in Wide-Char umwandeln ist nicht so einfach. Da brauchst du gar nicht an:

wchar_t*MyWideString=L"Jupidu";
char*MyMultiString=(char*)MyWideString;

zu denken (für den Fall, dass du noch von C# verwöhnt bist, was die Strings angeht). Auch strcpy kannst du vergessen, nimm lieber WideCharToMultiByte und MultiByteToWideChar .

CStoll

evilplayground schrieb:

Ach ja, und nochmal zum Thema:
Ich hab jetzt in meinem "Lern"-Projekt versucht, meine strings die ich mit WINAPI-Funktionen austauschen muss, als TCHAR zu definieren.
Wobei ich bei den einfachsten Sachen wieder auf Probleme stoße.
Bspl. Ich definiere eine variable TCHAR* path und lass mir diese über GetModuleFileName(..) füllen. Funktioniert auch wunderbar. Jetzt würd ich path aber noch gerne abändern mit ein paar Funktionen aus der "String.h" strcpy und so... Jetzt erwarten diese aber wieder eine variable vom Typ char*...

So, Noobfrage: Ich denke hier muss ich wohl casten, oder?
Wenn ja, wie?

Afair gab es für die string.h-Funktionen auch Hilfsmakros (z.B. _tcslen()), die je nach Setting entweder auf die char- oder wchar_t-Version umgeleitet werden.