so who uses them? how often do you use them? what do you use them for? my main issues is, i think im using them too much. I thinking of just seperating the main modules of the engine: * engine * scene * render * sound * network * physics would you put all your math classes in physics or engine? also, would scene be a subset of engine? Cheers -Danu

namespaces are more popular with the newer managed languages (C# and Java for example). In Java there was a convension of using a registered url backwards (eg net.gamedev.foobar) and a namespace==subdirectory.

namespaces are useful if you are planning on using other peoples code because it means functions like "void Quit()" will not clash with your own "void Quit()".

Because C++ is a bit more old-school and people tend to abbreviate more, namespaces names tend to be shorter (boost, std) rather then long (System.Web.UI.WebControls).

Anything I think is going to be linked elsewhere (dlls, libs) I try and give a unique namespace too if I think there will be function & class name clashes.

I don't think C++ is "oldskool" at all. Just that there are a whole lot of C people out there who write really quirky code ;)

Each project usually has its own namespace, larger projects have sub-namespace. My game engine, for example, is organized like this:

  + Nuclex    + Video      o VideoDriver (class)      o VideoDevice (class)    + Audio      o AudioDriver (class)      o AudioDevice (class)    + Text    + Math (imported into main namespace)    + Support (imported into main namespace)    + Storage    + GUI    + Script    + Scene

Forward-Declaring classes in other namespaces wasn't too much effort, imho. My project's components seldomly have more than two or three dependencies on other components, much less to components outside their own namespace.

-Markus-

I use namespaces fairly often. Within a single program, I'll most often use them for groups of assorted "utility" functions that don't make sense as part of any one class. This is usually MiscUtil::foo() or something similar. Aside from that, though, most things are encapsulated within classes, so I don't need namespaces much in that case.

Where namespaces really come into their own is when you start doing code reuse or sharing code across projects. In these cases, I set up something like this:

// SomeLibraryExportsnamespace SomeLibrary{  #include "ClassA.h"  #include "FooBaz.h"  ... etc ...};

Internally, the SomeLibrary modules will directly include the headers they depend on, while external clients can simply include the "exports" header and have the complete package wrapped in a nice, handy namespace. It takes a little bit of header juggling to get it to work out, but it's a very convenient and powerful setup. It really starts to shine when you need to split a module out of the main codebase, either to freeze the code or to share it with another project; a couple of compile-time parameters change (e.g. to link to a .lib instead of building the code directly) and you're golden.



For the OP's design question, I would have a separate math library if there is that much generic code that could be reused (e.g. vector/matrix operations). If there isn't enough common code to justify such a separation, I'd completely hide the mathematical aspects of each module inside the module itself, and implement the specific functionality needed in each side.

Personally I don't see why "scene" would be a subset/subclass of "engine" - a scene is a block of data, and the engine is what puts the scene data onto the screen. Engine is a consumer of scene, but scene should be agnostic of engine; this doesn't fit with the requirements for defining scene as a subclass or subset of engine. I do notice that you have a separate "render" and "engine" in your list - what is this for?

wow, thanks for all your guys inputs!!

i seperate render and engine because i treat my rendering engine as an entirely seperate engine, its abstracted away from the engine and will be implementing a primary OpenGL backend as well as a rudamentry D3D9 backend.

Cheers
Let the discussion continue!

-Danu

In that case I would suggest changing the design a bit. A more effective model would be to have an Engine which consumes a Scene. Engine is a base class (probably an abstract base), and your interfaces to OGL, D3D, etc. are implemented by subclassing Engine and adding the appropriate API-specific code. The less the rest of your design knows about how Engine works, the better.

... or is that what you're already doing, and I'm just confused about the way the class hierarchy is set up?