# [C++] namespaces

## Recommended Posts

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

##### Share on other sites
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.

##### Share on other sites
I use one namespace that wraps my entire project. I started out as you did, with different namespaces around different part of the engine. But I found out that it was a bitch to forward declare classes!

Instead of just writing 'class CFoo;' you must write:
namespace NFoo
{
class CFoo;
}

And it gets really annoying when you don't remeber what namespace CFoo actually lies in...=)

I would put Math in engine and Scene as a subset of Engine.

##### Share on other sites
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-

##### Share on other sites
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?

##### Share on other sites
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

##### Share on other sites
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?

##### Share on other sites
Quote:
 I'm just confused about the way the class hierarchy is set up?
I thought the list of modules basically was a list of separate libraries, each of which contains a bunch of classes. And by 'Scene' I assumed he ment everything regarding the scene graph and its classes(?), which I think is a bit overkill to put in its own lib

##### Share on other sites
I've been putting my entire project in its own nsmespace for awhile. I'm now starting to use additional namespaces within that, however, I only use them for divisions at the highest level. Right now, I create additional namespaces for each "package" in a project. Packages are self-contained segments that manage a perticular task. In my 3D engine, I have a Scene namespace for example which is used by my scene management package. I also have a Resource namespace which is used by my resource management package. There will also be a Renderer namespace for my renderer package.