Wie vermeide ich Redundanzen bei Funktionen für LPCSTR, LPCTSTR und LPCWSTR?

[CodeFinder]

Ist aber nicht unbedingt sinnvoll, da Du dann beispielsweise auch UNICODE-Funktionscode dabei hast, obwohl Du auf ANSI-Zeichensatz compilierst, aber hängt natürlich vom Kontext ab .

[NES-Spieler]

Genau so ist es ja auch gedacht: Wenn der Benutzer das nehmen will, was durch das Definieren oder nicht Definieren des UNICODE-Makros angedacht ist, dann nimmt er den Datentyp LPCTSTR und der Compiler sucht die richtige Funktion aus. Wenn er etwas unabhängig von diesem Makro machen will, nimmt er entsprechend LPCSTR oder LPCWSTR.

Es geht mir einfach nur darum, daß in meinen Funktionen genau das möglich ist, was auch mit den Original-Windows-Funktionen möglich ist: Man kann zwar dieses Makro festlegen, um generell zu sagen, ob man nun standardmäßig mit Unicode arbeiten will oder nicht, aber trotzdem kann man das Makro auch an gewissen Stellen ignorieren, wie in der WinAPI, wenn man direkt mit den A- oder W-Funktionen arbeitet.
Ich meine, hätte man gewollt, daß es immer vom Unicode-Makro abhängt und man dieses nicht übergehen kann, hätte man die A- und W-Funktionen ja ausschließlich in den ursprünglichen C-Dateien definieren können und das, was jetzt das Makro ist, wäre dann eine richtige Funktion, etwa so:

Header-Datei:

int MessageBox (HWND hWnd, LPCTSTR lpszText, LPCTSTR lpszCaption, UINT nType);

Quellcode-Datei:

int MessageBoxA (HWND hWnd, LPCSTR lpszText, LPCSTR lpszCaption, UINT nType);
int MessageBoxW (HWND hWnd, LPCWSTR lpszText, LPCWSTR lpszCaption, UINT nType);

int MessageBox (HWND hWnd, LPCTSTR lpszText, LPCTSTR lpszCaption, UINT nType)
{
    return
#ifdef UNICODE
    MessageBoxW
#else
    MessageBoxA
#endif
    (hWnd, lpszText, lpszCaption, nType);
}

int MessageBoxA (HWND hWnd, LPCSTR lpszText, LPCSTR lpszCaption, UINT nType)
{
    //Blablabla
}

int MessageBoxW (HWND hWnd, LPCWSTR lpszText, LPCWSTR lpszCaption, UINT nType)
{
    //Blablabla
}

Aber nein, der Benutzer hat vollen Zugriff auf alle drei Versionen und kann sowohl abhängig, als auch unabhängig vom Unicode-Makro arbeiten. Das gleiche soll bei mir auch möglich sein.

[mgs_]

Ich meine, hätte man gewollt, daß es immer vom Unicode-Makro abhängt und man dieses nicht übergehen kann, hätte man die A- und W-Funktionen ja ausschließlich in den ursprünglichen C-Dateien definieren können und das, was jetzt das Makro ist, wäre dann eine richtige Funktion

Nein, denn bei Funktionen, die sich nur im Rückgabetyp unterscheiden, funktioniert das Überladen nicht.

[CodeFinder]

Ich wiederhole mich einfach mal, dann weißt Du, das Dein Post eigentlich überflüssig war , aber ist nicht böse gemeint (hoffe das kommt nicht so an ).

CodeFinder schrieb:

[...] aber hängt natürlich vom Kontext ab .

mgs_ schrieb:

Ich meine, hätte man gewollt, daß es immer vom Unicode-Makro abhängt und man dieses nicht übergehen kann, hätte man die A- und W-Funktionen ja ausschließlich in den ursprünglichen C-Dateien definieren können und das, was jetzt das Makro ist, wäre dann eine richtige Funktion

Nein, denn bei Funktionen, die sich nur im Rückgabetyp unterscheiden, funktioniert das Überladen nicht.

Das stimmt zwar, aber Seine Parameter sind ja verschieden (LPCSTR != LPCWSTR).

[mgs_]

@Codefinder

Zunächst mal kann in c sowieso nicht überladen werden, und die WinApi-Schnittstelle ist in c realisiert.

Aber selbst in c++ funktioniert Polymorphismus nur für Aufrufparameter, nicht für Rückgabeparameter. Wenn zwei gleichnamige Api-Funktionen sich nur im Rückgabeparameter unterscheiden (TCHAR, d. h. char und wchar), ist Überladung nicht möglich.

[NES-Spieler]

Zunächst mal kann in c sowieso nicht überladen werden, und die WinApi-Schnittstelle ist in c realisiert.

Deshalb habe ich ja auch von meinen eigenen Funktionen gesprochen, die definitiv in C++ geschrieben werden.

Aber selbst in c++ funktioniert Polymorphismus nur für Aufrufparameter, nicht für Rückgabeparameter. Wenn zwei gleichnamige Api-Funktionen sich nur im Rückgabeparameter unterscheiden (TCHAR, d. h. char und wchar), ist Überladung nicht möglich.

So ist es ja bei mir auch nicht:

void MeineFunktion (LPCSTR text);
void MeineFunktion (LPCWSTR text);

Verschiedene Aufrufparameter. (Und der Rückgabewert ist hier nichtmal anders.)

[geeky]

Wozu braucht man noch was anderes als Unicode ?

[NES-Spieler]

Damit ich einem Benutzer von Windows 95/98 nicht sagen muß: "Bitte update Dein Betriebssystem auf Windows 2000 oder höher, um mein 50 KB großes Programm zu starten." Ach ja, und damit ich selbst meine Anwendungen benutzen kann (Windows 98).

[geeky]

http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx

[NES-Spieler]

Und damit ich für meine Anwendungen nicht irgendwelche fetten DLL-Dateien mitliefern bzw. statisch linken muß. (Erst recht nicht, wenn Unicode eigentlich gar nicht gebraucht wird. Ich meine, ich benutze in meinen Programmen ja nicht ständig zum Beispiel die japanische Sprache.)
Außerdem will ich den Benutzern meiner allgemeinen Quellcodes/Libs nicht sagen müssen, daß sie erst so einen Layer runterladen sollen, um 50 KB große Programme zu schreiben.

[CodeFinder]

@NES-Spieler: Jo Deinem letzten Post kann ich nur zustimmen, seh ich genau so.
@mgs_: Ich hoffe Du weißt jetzt, was ich meinte .

[mgs_]

@NES-Spieler und Codefinder
Meine Ausführungen zum Überladen bezogen sich auf NES-Spielers Argument:

Ich meine, hätte man [... bei Microsoft ...] gewollt, daß es immer vom Unicode-Makro abhängt und man dieses nicht übergehen kann, hätte man die A- und W-Funktionen ja ausschließlich in den ursprünglichen C-Dateien definieren können und das, was jetzt das Makro ist, wäre dann eine richtige Funktion

Ich habe lediglich eine sinnvollere Begründung dafür genannt, dass Microsoft diese Makros verwendet. Ein Überladen wäre eben nicht möglich gewesen.

[NES-Spieler]

Ich habe lediglich eine sinnvollere Begründung dafür genannt, dass Microsoft diese Makros verwendet. Ein Überladen wäre eben nicht möglich gewesen.

Ich habe auch nicht davon gesprochen, dass Microsoft die Funktionen hätten überladen können, wenn sie gewollt hätten, daß alles vom UNICODE-Makro abhängt, sondern meine Denkweise war so: Hätte Microsoft gewollt, daß die Verwendung von Unicode ausschließlich vom UNICODE-Makro abhängt und nicht auch individuell getätigt werden kann, dann hätten sie auf die Funktions-Makros verzichten und ihren Code so schreiben können:

Header-Datei:

int MessageBox (HWND hWnd, LPCTSTR lpszText, LPCTSTR lpszCaption, UINT nType);

Quellcode-Datei (C-Datei):

int MessageBoxA (HWND hWnd, LPCSTR lpszText, LPCSTR lpszCaption, UINT nType); 
int MessageBoxW (HWND hWnd, LPCWSTR lpszText, LPCWSTR lpszCaption, UINT nType); 

int MessageBox (HWND hWnd, LPCTSTR lpszText, LPCTSTR lpszCaption, UINT nType) 
{ 
    return 
#ifdef UNICODE 
    MessageBoxW 
#else 
    MessageBoxA 
#endif 
    (hWnd, lpszText, lpszCaption, nType); 
} 

int MessageBoxA (HWND hWnd, LPCSTR lpszText, LPCSTR lpszCaption, UINT nType) 
{ 
    //Blablabla 
} 

int MessageBoxW (HWND hWnd, LPCWSTR lpszText, LPCWSTR lpszCaption, UINT nType) 
{ 
    //Blablabla 
}