Have a question, tho it requires some BG:
I've got two classes, here:
#ifndef RENDERER_H
#define RENDERER_H // It's really a lot longer than this
class surface
{
public:
surface ();
virtual ~surface ();
virtual void somefunc () = 0;
};
class image; // defined elsewhere
class renderer
{
public:
renderer ();
virtual ~renderer ();
virtual surface& create_surface (image& image) = 0;
virtual void render_surface (surface& blah) = 0;
};
And I have a .DLL that derives from this interface
#ifndef INCLUDED_SDL_RENDERER_H
#define INCLUDED_SDL_RENDERER_H
class sdl_surface : public surface
{
public:
sdl_surface ();
~sdl_surface ();
void somefunc ();
};
class sdl_renderer : public renderer
{
public:
sdl_renderer ();
~sdl_renderer ();
sdl_surface& create_surface (image& image);
void render_surface (surface& blah);
};
Here's the problem I have: in render_surface, how to convert it back to a sdl_surface. I've come up with two options:
1) use dynamic_cast, and if I don't get something valid, either no-op, or throw an exception
2) implement a magic cookie system (using unsigned ints) to refer to the surfaces, and storing them in a map -> std::map (Well, I've got a special pointer class and not a sdl_surface, and a typedef instead of unsigned int, but you get the point =)
Wondering if there are any other options I haven't considered, cause I don't think RTTI is a good option (dynamic_cast). Also, instead of the magic cookie system, I'd rather have users just keep track of pointers, if possible. They're going to be using them to manipulate the surfaces directly, so that would be simpler, and they wouldn't have to come up with enums, or me come up with "unique random numbers"
The only reason I'm using an inheritance scheme is since the "renderer" will be loaded from a .dll, and there's no way for the main library to know which renderer will be loaded. I can't think of any non-inheritance scheme to make this work, that's simple, and doesn't involve crazy hacks...
Of course there's always the "all implmentations known at compile time" deal, along with simple switch statements for which to use, but that takes some of the fun, and purpose, out of coming up with a plugin system =)
Anything I've missed? Any bright ideas?
And no comments, please, on the speed this particular approach disallows, or how idiotic it is. I still wanna do it, and see for myself exactly how slow it'll probably be =)
[edited by - kavika on March 5, 2004 10:59:38 PM]
[edited by - kavika on March 5, 2004 11:00:29 PM]
