WinApi Funktionen als Methodennamen?

EXDW

die standardfunktionen von c++ sind in den namespace STD definiert, daher kommt man mit diesen nie in die quere,

ausser man ist so bloed und macht using namespace std;

die winapi funktionen sind leider in keinen namespace da es das fuer c noch nicht gab, daher sind die global immer bekannt, durch deine deklaration "dachte" der compiler das du die funktion ueberladen willst, darum sollte A und W auch noch ueberschrieben werden {in diesem fall A}

in einem eigenen namespace hast du keine probleme mit konflikten, egal welchen namen {ausser main glaub ich}

Eine Nachfrage: Wenn ich einen eigenen Namespace aufmachen, wie komme ich dann da wieder raus? Wenn ich doch mal eine WinApi Funktion benutzen will, was schreibe ich dann da?

EXDW

namespace ABC {
class MyClass {
void SetComputerName(string sCompname) {
}
}
} // namespace

spaeter dann nur
ABS::MyClass class();

das ist deine klasse in deinem namespace, wenn du daraus eine funktion benutzen willst musst du den namespace stets mit angeben - also

ABS::MyClass class();
sobald du die klasse instanziiert hast, benutzt du dort die funktion
class.SetComputerName();
wenn du keine klasse sondern eine globale funktion in dem namespace hast benutz du diese so
ABS::SetComputerName();

Wenn du den bloedsinn des using namespace verfallen bist kannst du mit
::SetComputerName()
die WinAPI funktion aufrufen

ps. einen "Namespace aufmachen" macht so kein sinn, du teilst durch den namespace deine funktionsnamen vom restlichen code, du steigst da nicht rein oder raus, sondern rufst entweder eine globale funktion oder eine funktion aus einem namespace auf

wenn du zb cout willst, musst du std::cout machen da cout im namensbereich std definiert ist
(using namespace ist eh ganz boese, lass es bleiben)

ps. das ist eher ein topic fuer c++ als mfc

Martin Richter

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.htm

HAbe ich etwas nicht beachtet?

MFK

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 Richter

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 Richter

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 Richter

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...