   Possibly a design problem?
  I am currently writing a platform-independent and api-independent engine. Things are going great, but I have run into a small problem. I wondered if you guys would be so kind as to make suggestions for me.For the Win32 renderers I have DirectX and OpenGL. Both of which require an HWND to initialize. So in the engine I have cPlatform which (in the case of Win32) creates a window and holds the HWND. Then I also have a cRendererManager which manages the lifetime of any given renderer. The cRendererManager class will find any file which could be a renderer and loads the chosed one. At which point it queries cPlatform for its HWND and passes it on to the renderer.My problems are thus:- This design means that in Win32 the interface between exe and renderer pass an HWND. In other platforms the interface is different. I have been unable to find a way to make the interface constant (and still logical) so I have somewhat coped with this problem.- cRendererManager now needs to grab and pass an HWND, making it platform-dependent. I feel the cRendererManager shouldn''t have to be dependent.If you guys know a good way for me to design this such that cRendererManager isn''t platform dependent (or if you have a good suggestion in general) please help me out. Thank you. 
  Method 1:Use a void* for platform-specific data along with conditional compilation if necessary (to cast back to the real type).Method 2:Use typedefs whose definitions differ by platform:typedef HWND MyWindowT;Method 3:Use a toolkit like GLUT or SDL (this implies you drop your API independence in these two cases). ;  I do almost like you do but instead of passing the HWND to the renderer the renderer retreives the HWND from the class that creates the window. That way a window sepcific renderer can retreive the HWND and the interface to the renderer will have no trace of windows stuff in it./Q ;  Quirk - I like your idea. I wonder though...see right now cPlatform is a singleton. It tracks itself using a static member. I couldn''t simple add the singleton code to the renderer because it would create two instances of the singleton.IE the exe would have a static and the renderer would have a static.I suppose the solution is to pass a pointer to the singleton to the renderer.Thanks for your comments. I really appreciate the help. ;  Don''t quite see why cPlatform being a singleton is a problem, surely whenever you reference it you''ll just do   cPlatform::Instance()->hWnd;  Or something of that nature...I don''t see why cPlatform would be in any danger of getting 2 instances... ;  use double dispatch class Platform {public:    virtual void initialiseRenderer(Renderer&);    virtual void initialiseRenderer(Win32OpenGLRenderer&);    virtual void initialiseRenderer(OSXOpenGLRenderer&);};class PlatformWin32 {public:    virtual void initialiseRenderer(Win32OpenGLRenderer& rend) {   rend.platformSpecificInitialisationUsingHWND(hwnd);    }private:    HWND hwnd;};class Renderer {    virtual void initialise(Platform&);};class Win32OpenGLRenderer : public Renderer {public:    void initialise(Platform& platform) {   platform.initialiseRenderer(*this);//will resolve to initialiseRenderer(Win32OpenGLRenderer&);    }    void platformSpecificInitialisationUsingHWND(HWND);};Platform* platform = new Win32Platform;Renderer* rend = new Win32OpenGLRenderer;rend->initialise(*platform);// This shows that you can abstract to just a platform and a renderer.// The double resolution of virtual functions allows you to call exactly the function you want with the data you wantIf you don't understand, please say what doesn't make sense.   [edited by - petewood on February 5, 2004 7:39:56 AM];  The problem is that the singleton also maintains a reference count so it knows when to destroy itself.About the double dispatch. I would rather not hard-code the renderers. ;  Analysis paralysis! Where you spend so long worrying about the ''right'' approach that you could have coded 100 ''good-enough'' approaches already.   There''s nothing wrong with having a simple switch statement or the odd cast or two in a situation like this. It''s not like the number of platforms you''re supporting is going to grow exponentially.Your platform classes can hold API-specific data. They can also tell the renderer what type they are via a generic GetType() function. Or use RTTI. Therefore the specific renderer can accurately downcast the platform class to a Win32Platform or an OSXPlatform and call Win32Platform::GetHWND() or whatever is necessary. No matter what you do, somewhere in your code is going to have to be able to make a decision based on the type of the platform, and hiding it behind 2 layers of virtual functions doesn''t really make it any cleaner.   [ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost  Asking Questions | Organising code files | My stuff | Tiny XML | STLPort] ;  I had a similar problem and here''s what I did - if it''s any help (I''ve tried to apply it to your design - hopefully I''ve got it right).Have a standard API/Platform neutral interface - IPlatform.Use the factory pattern to create the required concrete type which implements this interface for the specific platform you''re using - so you''d have PlatformWin32 for windows.Now you only need the HWND for plaftform specific stuff - ie the code that needs the HWND knows about it and is specific to Win32 - because of this it can use more than just the IPlatform interface - ie PlatformWin32 can have additional things - an operator or method that gives the HWND for example.  This doesn''t break the API/Platform independence because only internal platform specific code (and you have to have some of that!) needs to know about the actual concrete type implementing IPlatform.Hope that makes some sense..;quote:Original post by ProgramMax  About the double dispatch. I would rather not hard-code the renderers.Okay, you''ll need to hard code the platforms then. Have you completely abstracted the renderer and are loading them from DLLs. Is that what you mean by finding a file? The renderer will have to be able to get hold of an interface to a specific platform to be able to get what it needs to be correctly initialised. Maybe it doesn''t fit into how you see your design because I put all the renderers on the Platform class. How about having it as a RendererInitialiser class which you subclass for each platform. The RenderManager would have to know about one for each platform and the the renderers would be able to query the RenderManager to get the platform specific RendererInitialiser.Does that make sense? It''s just turning around the dispatch and putting it on an Initialiser rather than the Platform class. 