namespaces!!!!

Namespaces are used to help prevent naming clashes in different code modules. For example, lots of graphics programs and libraries have their own Vector3 definition. Namespaces allow same-named types to be used simultaneously. Personally, I'm happy when I see code that uses namespaces because I know it's going to be less troublesome to work with.

I say you should always use namespaces, even if your usage is a simple as having one namespace called "MyGame". Whatever you do, don't go namespace crazy and create more namespaces than you need. Keep the number and depth of your namespaces small and general so that you can your code stays flexible. This is important because if you end up moving things around and you have to rename your namespaces, you won't create extra work for yourself.

The only time you shouldn't use namespaces is if you are certain the code will need to be compiled with a compiler that does not support namespaces. I've not worked with such compilers, so I don't know how relevant this issue even is.

Quote:

Original post by Nedelman The only time you shouldn't use namespaces is if you are certain the code will need to be compiled with a compiler that does not support namespaces. I've not worked with such compilers, so I don't know how relevant this issue even is.

It's not an issue. If it is, you are using a compiler that does not support C++.... (eg fortran compiler??)

With regards to namespaces though, a lot of it simply comes down to personal preference. If you are working alone, then it's simple to choose to use them or not. It's up to you. If you are working within a team then it can become a real useful feature to be able to label code as 'runtime' 'tools' 'common' etc. That way you know if code is part of the 'tools' namespace it shouldn't be used in the engine itself (of course, if you need it in the 'runtime' namespace, you might want to move it to common).

Really though, using a namespace per library is frequently all that you need. So, if you can pull common rendering code into a renderer.lib, you might as well put it in your 'renderer' namespace. It all comes down to nice ways to modularise your code at the end of the day....

Quote:

Original post by papitoricoWhy namespaces instead of big fat classes with objects in them, or friend classes?

classes tend to form objects. a namespace just says the things are in some way vaguely related. For example, if you have a ferrari and a skoda object type, you can imagine wanting a number of instances of those types (i'd like 50 ferrari's if possible!).

You could put them into the 'garage' class, but then ask yourself why? It makes sense to catagorise them as 'cars', but do they always want to live within a garage? If i had a ferrari, I assure you i'd be getting a few speeding tickets on the open road (OK, so i might lose my license and it'd be in the garage for a year or two after that, but that's another story).

So yeah, i tend to think of namespaces as catagorising functions and objects into something related (ie, cars, rendering stuff, audio stuff, gameplay code etc). Classes tend to be more akin to containment - ie, a 'spark plug' is contained within an 'engine', which is contained within a 'ferrari'....

If you're using a lot of 3rd party code, its often a good idea to put all of your own code into at least one namespace, just to make sure you dont have any naming conflicts with 3rd party stuff

For example, each of my headers looks like this:

/** * @file   [filename...] * @author [me...] * @date   [date...] * @brief  [description...] */#ifndef __MODULENAME__FILENAME_H__#define __MODULENAME__FILENAME_H__namespace engine{//HEADER CODE GOES HERE}#endif

and each of my source files looks like this:

/** * [Same comment block as in a header...] */#include "engine.h"#include <3rdPartyWhatever.h>#include <string>using namespace engine;

My engine isn't all in one namespace tho, there sub namespaces - one for each "module". I put each section of the engine into its own "module", which is can either be an executable, a static-library or a DLL.

E.g. the rendering headers look have something like

namespace engine{namespace renderer{//code here}}

and the rendering sources need:

using namespace engine;using namespace renderer;

Namespaces aren't needed if you dont like them, but it makes your code much more organised and more interoperable with other peoples code.

Thanks to all of you!!!!!!
I registered today and I already have 4 answers!! awesome!!!!


a final comment after reading your posts: I compare C++ namespaces to Java packages. They have the same goal, manageable code and good software arquitecture.


Thnx again!!!

pdta: you guys rock!!!

Quote:

Original post by Hodgman ... stuff with 'using' in ...

You do of course realise that by putting that 'using engine' at the top of the source file you have just completely negated the usefullness of namespaces in that file?

For example, if you 'engine' namespace defined a class 'vector' and the '3rdPartyWhatever.h' also defined a class 'vector' then by using that 'using namespace engine' at the top you've pulled your engine's vector into the same namespace as the '3rdPartyWhatever.h's vector and well... BANG!

Personally I find it saner to fully qualify the type in that situation, so you'd refer to your vector as 'engine::vector' and avoid any collisions.

You could also doing 'using' in a smaller scope, which in certain situations could be useful from a typing pov (although with automatic code complete functionality in many many IDEs these days you have to wonder about it a bit) if you know you wont cause a clash at that point.

using has some legitimate uses. The main one I can think of is when you have a class Foo in the Quux namespace, i.e. Quux::Foo. You define the class in Foo.h inside a namespace block, which is fine.

However, in Foo.cpp, it's a royal pain in the arse to have to type Quux::Foo::Blah all the time; everything in Foo.cpp is talking about Quux::Foo, not Zoit::Foo, so there's no reason to qualify the namespace all the time. A simple using namespace Quux; at the top of Foo.cpp makes it a lot cleaner. This becomes especially important if you have Foo, Bar, Baz, Bletch, and Blartificus classes all in Quux, and they refer to each other heavily. The default is to assume that a Quux::Bar is talking about a Quux::Foo, and if a Quux::Bar needs to talk about a Zoit::Foo instead, then you qualify the namespace.

Limited imports (i.e. using Quux::Foo; rather than using namespace) are also OK and Good Things. For instance, our project's precompiled header specifies using std::vector; and std::list since we use those classes very heavily. std::map will probably end up in there fairly soon as well.

As usual an important C++ principle applies, namely: put the using in the smallest scope possible, and/or nearest the code that takes does the "use". Rampant using namespace is almost always bad, and global-scope using blah is bad when only one function in the entire file actually uses blah.

Quote:

a final comment after reading your posts: I compare C++ namespaces to Java packages. They have the same goal, manageable code and good software arquitecture.

They have the same purpose, yes.

I personaly use namespaces simular to what Hodgman posted.
(Nice design, imo)

Quote:

Original post by phantom Quote: Original post by Hodgman ... stuff with 'using' in ... You do of course realise that by putting that 'using engine' at the top of the source file you have just completely negated the usefullness of namespaces in that file?

Yes, yes I do.

Its a balance between the usefulness of namespaces and the less-readable code that may result from having "core::graphics::renderer::" or multiple "using ..."'s unecessarily littered throughout a file...

I usually use "using namespace [current-module]" within the module-specific source files of each module for convinience. Module-specific source files also have shorter include-paths for module-specific headers.
Any non module-specific code (such as headers, or source for other modules) are free from the evil "using".

E.g.
within the HCI module most source files are 'using namespace engine' and 'using namespace hci', and they all 'include "hci.h"'. But within the graphics module most source files are "using namespace engine" and "using namespace graphics", and they all include "hci/hci.h".

If any of these source files have to interact with non-namespaced external code, then obviously I cut back on the using in those files.