'CreateWindowA' Macro

PuerNoctis

Hallihallo,

kurze Frage zu folgendem Code:

// Irgendein Header-File
typedef struct
     {
     // [...]
     }S_PARAMS;

class C_MYGUI
     {
     // [...]
     public:
          int CreateWindow(S_PARAMS Params);

     // ctor, dtor...
     }

Im Laufe der Includes wird vor der obigen Header die <windows.h> geladen.

Wenn ich meinen Code nun compile (ich nutze Eclipse mit Cygwin unter Windows, aber das dürfte unabhänging davon sein), dann meckert mir der GCC an, dass das Makro 'CreateWindow' für CreateWindowA() falsch verwendet wird. Da es sich eben um ein Makro irgendwo in der <windows.h> handelt, interessiert ihn mein Scope der Klasse natürlich wenig.

Die Frage die ich nun habe: Ist es gefährlich das Makro mit

#ifdef CreateWindow
     #undef CreateWindow
#endif

zurückzusetzen? Der Code ist zwar dann compilebar, aber ich weiß nicht, ob das irgendwelche Seiteneffekte nach sich zieht. Falls jemand eine Möglichkeit kennt das auch anders zu lösen, hätte ich auch kein Problem damit

Im Zweifelsfall benenne ich eben die Methode um... Danke schonmal für etwaige Hilfen.

Gruß,
PuerNoctis

_matze

Nach meiner Ansicht sollte vermieden werden, Namen aus dem PSDK oder sonst wo her für die eigenen Funktionen zu verwenden. In anderen Fällen könnte man wohl mit Namespaces arbeiten, aber in diesem Fall ist CreateWindow ein Präprozessor-define, so dass deine CreateWindow's eben durch CreateWindowA oder CreateWindoW ersetzt werden sollen. Das wird durch namespaces natürlich nicht abgefangen. Sehr ungünstig...

PuerNoctis

Hm, hab' ich mir schon fast gedacht, dass davon abgeraten wird diesselben Namen zu verwenden.... Ich geh' jetzt einfach auf Nummer sicher und lass die Defines von Microsoft in Ruhe und benenne meine Methoden um.

Falls jemand noch ne Anmerkung dazu hat, einfach schreiben.

Btw.: Ich verwende sogar Namespaces, aber klar, das kratzt den Präprozesser nicht die Bohne

Martin Richter

Ganz verstehe ich Dein Problem nicht.
Es gibt in den Windows Headern einige Makros die bestimmte Namen in eine A oder W Variante umdefinieren. Wenn das aber konsequent gemacht wird spielt es keine Rolle. Denn alle Vorkommnisse dieses Namens werden geändert.
Problematisch wäre es nur im Exportieren der Funktion in einer DLL.

Wenn man also eine Methode CreateWindow nennt, wird am ende eben CreateWindowA oder CreateWindowW daraus, aber eben überall im Programm soweit man eben die Windows Header immer nutzt!

PuerNoctis

Ich versuche das Problem etwas genauer zu erläutern:

Microsoft definiert in meiner 'winuser.h' folgendes:

#define CreateWindowA(lpClassName, lpWindowName, dwStyle, x, y,\
nWidth, nHeight, hWndParent, hMenu, hInstance, lpParam)\
//[...]
#ifdef UNICODE
#define CreateWindow  CreateWindowW
#else
#define CreateWindow  CreateWindowA
#endif // !UNICODE

Der Define für 'CreateWindow' verweist folglich (kein UNICODE gesetzt) auf das Makro 'CreateWindowA'. Logischerweise wird jedes 'CreateWindow' in meinem Code durch eben dieses Makro ersetzt.

Nun habe ich aber eine Methode in meiner Klasse, die zufälligerweise 'CreateWindow' heißt. Durch diese Defines wird meine eigene Methode zu einer WinAPI-Funktion umgeleitet <- und DAS ist das Problem

EDIT: Da ich die <windows.h> allerdings brauche, komme ich nicht drum herum, dass die obigen Defines irgendwann gesetzt werden. Ich hab' mit den Dingern rein garnichts zu tun...

Mein Lösungsansatz war nun, vor meiner Klasse das Define 'CreateWindow' mit #undef zurückzusetzen, nur ich bin mir nicht sicher, ob ich irgendwann nach weiterer Implementierung in Probleme laufen könnte. Hoffe das Problem ist jetzt etwas konkreter veranschaulicht.

Ich werde höchstwahrscheinlich meine Methoden umbennen um dem zu entgehen. Danke für Eure Antworten

MFK

PuerNoctis schrieb:

Nun habe ich aber eine Methode in meiner Klasse, die zufälligerweise 'CreateWindow' heißt. Durch diese Defines wird meine eigene Methode zu einer WinAPI-Funktion umgeleitet <- und DAS ist das Problem

Nein, das ist erst einmal kein Problem. Da wird nichts umgeleitet.
Ein Problem hast du erst, wenn diese Übersetzung nicht überall passiert, weil du irgendwo <windows.h> nicht einbindest, oder wenn die Ersetzung nicht überall gleich ist, weil du mal UNICODE definiert hast und mal nicht.

Martin Richter

100% ACK zu dem was MFK schreibt. Das wollte ich mit meinem Posting auch schon sagen.

Alles klar, danke für die Antworten.