WinApi Funktionen als Methodennamen?
-
An sich sollte das kein Problem sein. Wenn in alle Header Dateien auch windows.h included wird.
Aus SetComputerName wird durch einen define in der windows.h entweder SetComputerNameA oder SetComputerNameW. Das ist aber keine TRagik, wenn diese Umwandlung in allen Sourcemodulen passiert.
Das ganze wäre nur ein Problem, wenn die Library die DU verwendest oder eine der Sourcedateien nicht windows.h included!
-
Naja, der Getter ändert sich vom Namen her. Dann stimmt auch meine Doku nicht mehr...
Ich habe versucht das Bsp von Mr. Evil umzusetzen.
#include "stdafx.h" #include <iostream> #include "windows.h" namespace ABC { class MyClass { public: // Diese Funktion will ich dann wieder umbenennen. (X wegmachen.) void GetComputerNameX(std::string sCompname) { unsigned long length=100; char *sBuffer = new char[length]; std::GetComputerName(sBuffer, &length); // Hier die WinApi Funktion delete sBuffer; } }; } // namespace int main() { ABC::MyClass M; M.GetComputerNameX(""); return 0; }Der Kompilerfehler:
error C2871: 'ABC' : does not exist or is not a namespace
merkt diese Zeile an:
namespace ABC {Dem Beispiel von Shade nach sollte es aber so klappen:
http://tutorial.schornboeck.net/namespace.htmHAbe ich etwas nicht beachtet?
-
ABC ist bereits der Name einer WinAPI-Struktur. War ein schlechtes Beispiel. Jeder andere nicht bereits benutzte Name sollte funktionieren.
-
Ach so, Danke Euch allen

-
martin_salo schrieb:
Naja, der Getter ändert sich vom Namen her. Dann stimmt auch meine Doku nicht mehr...
Nein! Das tut er eigentlich nicht. Denn das er den Namen ändert sieht keiner!
Jeder der auch die windows.h verwendet sieht auch nur den alten Namen GetComputerName.Ich mache mir an dieser Stelle gar keine Gedanken, denn die Änderungen passieren ja im Hintergrund.
-
Weil sich beim Nutzer der Klassen der Name der Funktion auch ändern würde... ok.
-
martin_salo schrieb:
Weil sich beim Nutzer der Klassen der Name der Funktion auch ändern würde... ok.
Genau!
Einzig und alleine in dem "seltenen" Fall das windows.h nicht zum Projekt gehört, würde es ein Problem geben. Aber selbst dass kann man mit einem entsprechenden #ifdef prüfen und zur Pflicht machen...
-
Oder wenn man den Getter über eine DLL Schnittstelle exportiert und der DLL Nutzer auf der anderen Seite keine windows.h benutzt...
-
martin_salo schrieb:
Oder wenn man den Getter über eine DLL Schnittstelle exportiert und der DLL Nutzer auf der anderen Seite keine windows.h benutzt...
Wie soll er das machen? Die DLL benutzen ohne Header Datei, besonders wenn es sich um eine Klasse handelt? Du kanst in der Header Datei immer den entsprechendne Schutz unterbringen.
Bei selbst wenn GetProcAddress verwendet wird mit extern "C", kann man entsprechende Vorkerhungen treffen.
-
Ich geb mich ja ungern geschlagen, aber wenn der andere auch Martin heißt könnte ich dieses Mal eine Ausnahme machen...
