Proper use of Namespaces

It's down to personal style, but:

Quote:

Original post by caseyd Does it make sense to have a namespace for each class that I create

No, unless there are a bunch of non member functions that are closely related to the class in question and you want to make it obvious that they are related.

Quote:

Original post by caseyd or should I just have one namespace that encompasses my game?

Possibly. You can still nest namespaces inside this overall one.

Quote:

Original post by caseyd Should I instead use a namespace for each sub system

That's quite usual. You may want to split them down more after that, depending on size and complexity.

hope that helps.

Quote:

Original post by caseyd Should I instead use a namespace for each sub system, for example putting the Graphics routines in one namespace while the audio is in another? ~Casey~

That is usually how I've seen it done and the way I do it. I have typically worked on animation and physics subsystems, and I typically use different namespaces for each.

Let's say you're working on your engine named caseyd. In this engine, you have your video subsystem, audio, and user input. These all each contain about twenty different classes each. If you apply your namespaces correctly, you should have something like this:

• caseyd - All base classes
  
• caseyd::Video - Video related classes
  
• caseyd::Input - User input (keyboard, mouse, joystick, etc)
  
• caseyd::Audio - Audio output (music, sound, etc)

Then, using this caseyd engine, you decide to make a kick ass game named UltraDeathDestroyer. This UltraDeathDestroyer game is going to be really cool because it has a built-in particle engine, enemy management systems, etc. This will require a whole new namespace because it's a new assembly that uses the caseyd base engine:

• UltraDeathDestroyer - All base classes for the game
  
• UltraDeathDestroyer::Enemies - All derived enemy classes from the main enemy
  
• UltraDeathDestroyer::Particles - Particle engine
  
• ...etc.

Of course it's completely up to you how you'd set this up. Just make sure that each namespace has at least eight different classes. If it doesn't have at least eight classes, does it really need a whole new (sub)namespace? In my opinion, each new assembly requires a whole new base namespace (unless it's a plugin/addon).

Thanks for the info. I thought that the right way would be to seperate everything by subsystem. Thanks for confirming.

For instance some of my namespaces are:

Xainosis.Logging - all the classes and interfaces of my logging subsystem
Xainosis.Audio - audio processing classes, interfaces, enums, and functions
Xainosis.Settings - setting file reading / writing (this is my smallest namespace with only 3 classes)

Xainosis.Game - Core library code which deals with persistent game objects, object managers and shared interfaces

Xainosis.Governor2099 - Things related to my work not-really-in-progress Governor 2099 - such as the ShipDesign, SolarSystem, and Fleet classes

I have more namespaces than this (probably about 11 of any significance), but I started benifiting from namespaces when I had just 3: Logging, Utility, and Game ... the Logging was seperate from Utility because it was a very advanced and stable / reusable design (which I have used at 3 jobs), whereas my Utility and Game libraries were constantly changing ...

Resist the temptation to nest your namespaces too deeply. They are cool and all, but you can quickly make code a lot more unwieldly than it needs to be if you have a lot of namespaces floating around.

I tend to create a single 'root' namespace for a project, and avoid going any deeper than that unless I am having troubles with symbol conflicts. (which is uncommon in C++, since it has such nice overloading rules)