Windows Funktion ignoriern

Hi,
in der windows.h gibt es eine Funktion, die Rectangle heißt.
Nun möchte ich mir auch eine Funktion schreiben die Rectangle heißt, allerdings meckert da der Compiler. Kann ich dem irgendwie klarmachen, dass ich die Windows Rectangle Funktion ignoriere, ohne meine Funktion in einen eigenen Namespace zu packen?
Oder kann ich sogar alle Windows Funktionen in ein Namespace packen?

drakon

Möglichkeiten gibt es, aber ich rate dir dazu namespaces zu benutzen oder halt einen anderen Namen zu verwenden. Einen eigenen Namensraum ist imo der sauberste Weg, da es die ja genau dazu gibt.

Hmm, hab ich mir schon fast gedacht...
Aber gibt es irgendeine möglichkeit für die ganzen Windows Funktionen einen Namespace zu erstellen?

pumuckl

MagLieberLinux schrieb:

Aber gibt es irgendeine möglichkeit für die ganzen Windows Funktionen einen Namespace zu erstellen?

Nein. Was hindert dich, alle deine Funktionen in einen Namespace zu packen?
Dazu müsstest du nur in deinen Headern entsprechend den namespace mit angeben, in den .cpps kannst du je nachdem wo es sinnvoll ist durchaus using-direktiven benutzen.

Nexus

In Anwendungen (nicht Bibliotheken) finde ich es gar nicht so verkehrt, keinen Namensraum zu benutzen. Besonders wenn man ihn eh nie qualifiziert angibt. Was anderes ist natürlich, wenn die Anwendung mehrere modulare Komponenten in eigenen Namensräumen hat.

Aber hier kann man ohnehin Funktionsüberladung benutzen (es sei denn, man hätte die exakt gleiche Signatur).

pumuckl

Nexus schrieb:

In Anwendungen (nicht Bibliotheken) finde ich es gar nicht so verkehrt, keinen Namensraum zu benutzen. Besonders wenn man ihn eh nie qualifiziert angibt. Was anderes ist natürlich, wenn die Anwendung mehrere modulare Komponenten in eigenen Namensräumen hat.

Aber hier kann man ohnehin Funktionsüberladung benutzen (es sei denn, man hätte die exakt gleiche Signatur).

Funktionen sollten imo nur dann überladen werden, wenn die Überladungen so ziemlich das gleiche tun. Eine Funktion aus einer völlig anderen Bibliothek zu überladen mit etwas, was genauso heißt, aber was anderes macht, führt bei der Wartung schnell zu Missverständnissen, bei ähnlichen Signaturen sogar sehr schnell zu Fehlern.

Alternativ dazu, alles in einen eigenen Namespace zu packen, könnte man sich auch einen Header schreiben, um die WinAPI zu kapseln. Mal davon abgesehen dass sich die Zugriffe daraf sowieso nicht durch das gesamte Projekt ziehen sollten.

Nexus

pumuckl schrieb:

Funktionen sollten imo nur dann überladen werden, wenn die Überladungen so ziemlich das gleiche tun. Eine Funktion aus einer völlig anderen Bibliothek zu überladen mit etwas, was genauso heißt, aber was anderes macht, führt bei der Wartung schnell zu Missverständnissen, bei ähnlichen Signaturen sogar sehr schnell zu Fehlern.

Aus der Standardbibliothek:

// Aus <algorithm>
template <typename ForwardIterator, typename T>
ForwardIterator remove(ForwardIterator first, ForwardIterator last, const T& value);

// Aus <cstdio>
int remove(const char* filename);

Führt meiner Meinung nach nie zu Missverständnissen.

Und Überladung ist keine so schlechte Lösung, wenn man nicht wegen einer einzigen Funktion alles in einen Namensraum packen will (was ja wie erwähnt berechtigt sein kann).

pumuckl schrieb:

Alternativ dazu, alles in einen eigenen Namespace zu packen, könnte man sich auch einen Header schreiben, um die WinAPI zu kapseln. Mal davon abgesehen dass sich die Zugriffe daraf sowieso nicht durch das gesamte Projekt ziehen sollten.

Ja, das ist sicher eine gute Idee.

Danke für eure Antworten. Die Header in Namespaces zu stecken und in den cpps eine using-Direktive zu benutzen scheint mir sinnvoll.
Überladung scheint nicht zu funktionieren, da meine Funktion Rectangle der Konstruktor der Klasse Rectangle ist

pumuckl schrieb:

Alternativ dazu, alles in einen eigenen Namespace zu packen, könnte man sich auch einen Header schreiben, um die WinAPI zu kapseln. Mal davon abgesehen dass sich die Zugriffe daraf sowieso nicht durch das gesamte Projekt ziehen sollten.

Kannst du mir eklären wie das gehen soll?
Ist das dann so eine Art Wrapper der so aussieht:

HWND myCreateWindowEx() {
    return createWindowsEx();
}

Weil das erscheint mir nach sehr viel Arbeit...

dot

Das größte Problem mit windows.h in dem Zusammenhang ist dass viele WinAPI "Funktionen" in Wirklichkeit Makros sind die je nach Buildconfig die ANSI oder Unicode Version der Funktion aufrufen und dann helfen alle namespaces der Welt nichts mehr. Ich würde eher versuchen möglichst nicht einfach überall windows.h zu inkludieren und wenn dann nur das notwendigste (gibt da alle möglichen #defines um nur benötigte Teile reinzuholen). Eigentlich lassen sich solche Namenskollisionen fast immer irgendwie vermeiden...

pumuckl

MagLieberLinux schrieb:

Kannst du mir eklären wie das gehen soll?
Ist das dann so eine Art Wrapper der so aussieht:
HWND myCreateWindowEx() {
    return createWindowsEx();
}
Weil das erscheint mir nach sehr viel Arbeit...

Je nachdem, wie viel von der windows-Funktionalität du benutzt kann das durchaus viel Arbeit sein.
Normalerweise solltest du aber deine Software so aufbauen, dass nur ein geringer Teil der Software die winAPI benötigt, quasi die unterste Schicht eines deiner Module. Nur in dessen .cpp brauchst du die windows.h, überall sonst ist das nicht nötig.
Zu dem Zweck gibts viele Muster/Idiome, ein paar Schlagworte zum googlen:
- Multitier Architecture
- Abstraction layer
- pimpl idiom