State with namespaces and locals - or classes?

Right now, the modules in my game engine are organized as namespaces. They have Open() and Close() functions which act similar to constructors and destructors of classes, and are called when the game is entered left.

Examples for these modules are: The physics manager, entity manager, I/O handler, rendering manager.

Now, I'm beginning to think that it is bad to have all the variables of the modules "lying" around and being exported globally via the linker.

Refactoring the modules from namespaces into classes would bring the following overhead:

• There would have to be a global controller which allows interaction between the different modules, by proving access to their instances

• Int开发者_开发知识库eraction between modules would get the extra overhead of a function call and 1-2 pointer dereferences

And the following advantages:

• RAII conform
• All state could be packed into a single CState class which contains the instances of the modules
• Good for making sure that resources are deleted and allocated properly

My questions:

• Should I consider refactoring my engine modules from namespaces to managed classes? Why (not)?

If you have a set of functions (methods) that operate on a collection of objects that shouldn't be visible to other functions outside of that set then it would seem natural to put that collection of functions and objects in a class.

There would have to be a global controller which allows interaction between the different modules, by proving access to their instances

Does there have to be a global controller? This sounds very much like the "God object" anti-pattern. Even if you only usually have a single instance of each of your classes, they don't all have to be a member of an overall controller class so long as the functions in the various classes that need access to other classes have a way of getting that access.

Interaction between modules would get the extra overhead of a function call and 1-2 pointer dereferences

I'm not sure how you've worked this out. I don't believe that this has to be the case but I would recommend that you design for clarity first and the optimize only if the performance isn't adequate.

If there is state involved, then creating a class so that you can have multiple instances of the state is good.

However, there are other pros and cons:

• namespaces are open, classes are closed. You can add stuff to a namespace more easily.

• You can make forward declarations of stuff in namespaces more easily. You can't do forward declarations of stuff in a class - the whole class declaration must be visible.

• this means that namespaces are a bit easier to do the moral equivalent of PIMPL in. You can just forward declare the functions you need. With a class, you need to actually build a PIMPL - which is tedious.

I would like to think that a namespace is just a class that has no data, or a class that only contains class static data. I.e. a namespace is something like a class that you cannot have objects of. But, unfortunately, many limitations of C++ prevent this from being literally true.

• Sometimes I end up with both a namespace and a class.