Es gibt ja 3 Arten von ValueTypes in Registry:
REG_SZ
REG_DWORD
REG_BINARY

und Abarten von diesen drei:
REG_MULTI_SZ
REG_EXPAND_SZ

so habe ich mir gedacht, dass ich es mit Abstrakter Klassen mache

enum REG_TYPE
{
	REG_SZ,
	REG_DWORD,
	REG_BINARY
};

class Key
{
	private:
        protected:
		HKEY hKey;
		std::wstring path;
		std::wstring KeyName;

	public:
		virtual void* read() = 0;
		virtual bool write(std::wstring name, void* value) = 0;
		/*
		* Je nachdem, welche Childclass kommt, wird value ein std::wstring oder DWORD
		*/
		virtual std::wstring getName() = 0;
};

class KeySZ : public Key
{
	private:
		std::wstring value;
	protected:
	public:
	bool write(std::wstring name, void* value);
	std::wstring getName()
	{
		return this->KeyName;
	}
};

bool KeySZ::write(std::wstring name, void* value)
{
	[...]
	LONG lRes = RegSetValueExW(this->hKey, name.c_str(),0,NULL,(const BYTE*)((std::wstring)value).c_str(),((std::wstring)value).length());
	[...]
}

Der Sinn meines Gedanken ist:

typedef std::map<std::wstring,Key> MKey;

class RegTree
{
	public:
		typedef std::map<std::wstring,RegTree> MTree;
	private:
		MKey Keys;
		MTree Trees;
	[...]
};

Somit könnte ich einen Container erstellen, der alle drei Arten von RegKeys beinhaltet.

Hat jemand eine gute Idee das zu realisieren?

Mit freundlichen Grüßen
Sepultura

Warum glaubst du, dass es eine gute Idee ist das Typsystem zu umgehen und Strings, Binärdaten und ints in einen Topf zu schmeißen? Da wirst du doch definitiv durcheinander kommen.
KeySZ::write sollte einen string nehmen und keinen void *. Weiterhin würde ich die Vererbung komplett weglassen, das wird nur schaden. Wenn es denn sein muss, dann sollte KeySZ private von Key erben, damit die void -Variante von write nicht benutzbar ist, die ist allein für die KeyBinary-Variante reserviert, wobei dafür noch ein Parameter für die Länge der void-Daten fehlt.
Warum willst du eigentlich Keys verschiedener Typen in eine map tun? Die kann man doch nicht vernünftig benutzen.

Wenn ich die Vererbung entferne, müsste ich also 3 Key Container für RegTree machen.

Damit würden auch drei Iteratoren entstehen, um alle Keys nacheinander durchgehen zu können.

wird das nichts mit "schönem" C++ und du brauchst type erasure.

type erasure ist schönes C++.

Nathan schrieb:

wird das nichts mit "schönem" C++ und du brauchst type erasure.

type erasure ist schönes C++.

Nein.
Die Implementierung ist zwar herrlich ( ), aber es ist kein schönes C++ im Anwendercode.

Ihr meint, ich soll Templates verwenden?

Nein.

Nein.
Die Implementierung ist zwar herrlich ( ), aber es ist kein schönes C++ im Anwendercode.

Genau umgekehrt. Die Implementierung von Type Erasure braucht relativ viel Boilerplate-Code und bei komplexeren Dingen ziemliche TMP-Tricks, aber die Anwendung könnte kaum schöner sein.

Bestes Beispiel: std::function
Schlechteres Beispiel: boost::any -- nicht weil die Klasse nicht gut entwickelt ist, sondern weil Leute sie einsetzen ohne sie zu benötigen.

Was nicht gut ist, ist explizite Fallunterscheidung (switch, if-else, RTTI). Gut ist Polymorphie.

KeySZ::KeySZ(HKEY root, std::wstring subkey, bool readonly)
{
	this->subkey = subkey;
	LONG lRes;
	if (readonly)
		lRes = RegOpenKeyExW(root, subkey.c_str(), 0, KEY_READ, &this->hKey);
	else
		lRes = RegOpenKeyExW(root, subkey.c_str(), 0, KEY_ALL_ACCESS, &this->hKey);
	if (lRes != ERROR_SUCCESS)
		throw "COULD NOT OPEN";
	TCHAR buffer[512];
	RegQueryValueExW(this->hKey, TEXT("Installer Language"), 0, 0, (BYTE*)buffer, (DWORD*)512);
	std::wcout << buffer << std::endl;
}

Ausgeführt wird der code so:

KeySZ test(HKEY_CURRENT_USER, TEXT("Software\\pidgin"), false);

Warum wirft RegQueryValueExW eine Zugriffsverletzung?

Alternative zu void* ? C++11

WARUM?

Was willst Du erreichen? Welchen Zweck verfolgst Du? Für jeden Zweck können wir Dich totwerfen mit hunderten von Lösungen, die ihrerseits je nach anderem Zweck besser oder schlechter wären.

Viele von uns wollen einfach nicht glauben, daß Du die Windows-Registry nachbilden willst. Die kommt nämlich direkt aus der Hölle.

Mach am besten, was Nathan und Nexus sagen. Die sind mir in vielen bisherigen Threads saupositiv aufgefallen, wie sie schwach anfangen und sich miteinander aufs Optimum aufschaukeln und nicht jemanden belästigend "belehren", sondern einfach helfen.

Außer hier gerade mal. Nuja, passiert.
Passiert mich auch (jetzt nämlich zum Beispiel!). Kannst die Registry nicht sinnvoll abbilden. "'Ääätsch!". Kannst aber schon irgendwelche Proxy-Objekte da ablegen und holen. Mehr aber nicht bitte. Und die schon sind zu objektorientiert. Lass es doch einfach bei den Zugriffsfunktionen. Die kannste ein wenig schmirgeln bei Bedarf.

KeySZ::KeySZ(HKEY root, std::wstring subkey, bool readonly)
{
	this->subkey = subkey;
	LONG lRes;
	if (readonly)
		lRes = RegOpenKeyExW(root, subkey.c_str(), 0, KEY_READ, &this->hKey);
	else
		lRes = RegOpenKeyExW(root, subkey.c_str(), 0, KEY_ALL_ACCESS, &this->hKey);
	if (lRes != ERROR_SUCCESS)
		throw "COULD NOT OPEN";
	TCHAR buffer[512];
	RegQueryValueExW(this->hKey, TEXT("Installer Language"), 0, 0, (BYTE*)buffer, (DWORD*)512);
	std::wcout << buffer << std::endl;
}

Ausgeführt wird der code so:

KeySZ test(HKEY_CURRENT_USER, TEXT("Software\\pidgin"), false);

Warum wirft RegQueryValueExW eine Zugriffsverletzung?

Wahrscheinlich weil dort

RegQueryValueExW( ..., (DWORD*)512);

steht. Hat der Compiler dort keine Warnung ausgeworfen? Dort lässt Du die Funktion auf ein Stück Speicher an der Adresse 512 zugreifen.
Du meinst sicher:

DWORD len = 512;
	RegQueryValueExW(this->hKey, TEXT("Installer Language"), 0, 0, (BYTE*)buffer, &len);

Und vergesse nicht, den Returnwert der Funktion auszuwerten!

Nathan schrieb:

Nein.
Die Implementierung ist zwar herrlich ( ), aber es ist kein schönes C++ im Anwendercode.

Genau umgekehrt. Die Implementierung von Type Erasure braucht relativ viel Boilerplate-Code und bei komplexeren Dingen ziemliche TMP-Tricks

Sagte ich doch: schönes C++. :p
Ich persönlich liebe es solche Probleme mit allen verfügbaren Mitteln zu lösen, ob es nun TMP-Hacks, Makros oder ähnliches ist.

, aber die Anwendung könnte kaum schöner sein.
Bestes Beispiel: std::function

Stimmt, an std::function hab ich gar nicht gedacht.

Schlechteres Beispiel: boost::any -- nicht weil die Klasse nicht gut entwickelt ist, sondern weil Leute sie einsetzen ohne sie zu benötigen.
Was nicht gut ist, ist explizite Fallunterscheidung (switch, if-else, RTTI). Gut ist Polymorphie.

Das Beispiel hatte ich im Sinn als ich schlechte Anwendung meinte.