Pimpl-Design

Badestrand

Aloha!

Ich doktore gerade ein wenig mit dem Pimpl-Idiom herum (wer's nicht kennt) und weiß noch nicht ganz, wie ich's mit den .cpp- und .h-Dateien handhaben würde, wenn ich eine Bibliothek schreiben würde. Aber auch unter Beachtung, dass ich verschiedene Implementationen für unterschiedliche Betriebssysteme haben würde.

Mein favorisiertes Design sieht momentan so aus, hat aber nicht mehr soo viel mit dem Pimpl-Idiom zu tun (ich hab der Einfachheit halber einfach mal eine simple Mutex-Klasse verpackt):

// Mutex.h
#pragma once

class Mutex
{
	public:
		Mutex();
		~Mutex();
		void lock();
		void unlock();

	private:
		Mutex( const Mutex& other );
		Mutex& operator=( const Mutex& other );

	private:
		void* m_data;
};

// Mutex.cpp
#include "Mutex.h"
#include "OS.h"

// Könnten genauso gut .cpp-Dateien sein, grad egal
#if defined SYSTEM_WINDOWS
	#include "Mutex_Windows.h"
#elif defined SYSTEM_LINUX
	#include "Mutex_Linux.h"
#elif defined SYSTEM_MACOS
	#include "Mutex_MacOS.h"
#endif

// Mutex_Windows.h
#include <windows.h>

struct Data
{
	CRITICAL_SECTION cs;
};
#define data (*static_cast<Data*>(m_data))

Mutex::Mutex() : m_data(new Data())
{
	InitializeCriticalSection( &data.cs );
}

Mutex::~Mutex()
{
	DeleteCriticalSection( &data.cs );
	delete m_data;
}

void Mutex::lock()
{
	EnterCriticalSection( &data.cs );
}

void Mutex::unlock()
{
	LeaveCriticalSection( &data.cs );
}

Hier mache ich mir halt Sorgen wegen dem Makro und dem void*-Pointer, ansonsten finde ich das eine schöne Lösung - weil's imo einfach erweiterbar und einfach wartbar ist.
Was sagt ihr dazu und kennt jemand noch bessere (wie auch immer geartete) Lösungen?

Dravere

Und wieso lässt du die Vorwärtsdeklaration weg, wodurch du den void-Zeiger und das Makro vernichten könntest? Das leuchtet mir irgendwie nicht so ein.

Grüssli

Badestrand

Oh je, wie recht du hast

edit: Dann hat sich der Thread ja gegessen, weil's ja direkt nach dem Pimpl spielt.. Danke Dravere..