quote:Original post by _the_phantom_
the class would still derive (sp?) from a common base class but would be totaly hidden from the external world.

So you DO have a base class -- your first post made it sound like you were not using a base class at all. Your argument then isn't about using namespaces instead of classes for a renderer, it's just should you use a namespace or a singleton to encapsulate the pointer used to interface with the current renderer.

quote:Original post by _the_phantom_
You now have no global objects in play as the render is hidden away inside a namespace and everything just seems a bit cleaner to my way of thinking.

This is really just a matter of "globals vs global access singletons" and it really comes down to what you personally prefer. Remember that not all singletons have to be globally accessable from all objects (in fact, to be safe, they really shouldn't be), and, particularly here, it would be better off NOT as globally accessable. For instance, not everything in your game should be able to construct and reconstruct the singleton with different renderer types. Only one particular class should be able to perform these operations (or function, if you're not into pure OOP design). If you really want to go with strict design, as I personally would suggest, you wouldnt have ANY part of the singleton be globally accessable from all types -- make it have a single friend which is the only class which manages construction and destruction of the object and have that class delegate references to the instance to any objects which need to perform drawing. This gives you extremly modular design while limitting reliance on global data and even restricts access to only the type which manages the singleton. Remember, you don't use a singleton as a replacement for globals, if you do, then you don't fully understand the concept of a singleton. You use a singleton to limit the instances of the type to one, whether or not there is global access to the instance is another matter. You should try to limit access as much as you can.
Again, all of this comes down to opinion. If you take the singleton approach you can make much of the improper use of your objects literally impossible to do because syntactically it would be invalid do to access restriction. By not using a singleton, you lose this benefit and just rely on documentation to tell users what they should and shouldn't do, but improper use becomes completely valid syntactically. In general, it's safer to take the singleton approach.

Edit:

quote:With either method you need a factory system to make the instance of the correct class (mygfxsystem::init("OpenGL") and off the top of my head i cant think how you'd do it for a singleton system), and the class would still derive (sp?) from a common base class but would be totaly hidden from the external world.

With a singleton system, and even without a singleton, if you aren't putting your renderers in DLLs, you can just make your "init" function templated. I don't recommend making it take a const char pointer.

Example:

template< typename RelatedType_t >  RelatedType_t* init(){  delete Instance;  Instance = new RelatedType_t;  return static_cast< RelatedType_t* >( Instance );}     

Now you can do, IE:
init< Direct3d >();
or
init< OpenGL >();

The same logic goes for singletons, except you can even abstract it to a singleton base type so that you don't have to redefine the function for all your singletons.

[edited by - Polymorphic OOP on October 23, 2003 11:31:01 PM]