# to namespace or not to namespace?

This topic is 4705 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

when does namespace partitioning become an overhead? i personally like to use a deep namespace hierarchy when i'm coding, like
namespace MyEngine {
namespace Core {
class Pipeline() {}
}
}

MyEngine::Core::Pipeline* pPipeline = new MyEngine::Core::Pipeline();


but i'd guess some of you out there will kill me for this, so how deep is your (eventual) namespace hierarchy?

##### Share on other sites
A library needs a namespace of it's own:

just library::

larger libraries I like subnamespaces:

library::audio, library::video, library::util, etc.

and for certain uses I throw in third level namespaces, generally for containing free functions instead of classes

library::util::filesys::

##### Share on other sites
Quote:
 when does namespace partitioning become an overhead?

Depends what you mean by overhead. It definitely won't effect anything performance wise.

As for how deep you should have a hierarchy I concur with cozman. The hierarchy you should there is fine. There's always namespace aliasing if it all gets a bit unwieldy.

##### Share on other sites
Quote:
Original post by Monder
Quote:
 when does namespace partitioning become an overhead?

Depends what you mean by overhead. It definitely won't effect anything performance wise.

As for how deep you should have a hierarchy I concur with cozman. The hierarchy you should there is fine. There's always namespace aliasing if it all gets a bit unwieldy.

what i mean with overhead is not by performance, but by typing...

consider:
Engine::Core::Pipeline* pPipeline = new Engine::Core::Pipeline;

Pipeline* pPipeline = new Pipeline;

what you mention with namespace alias must be the first evidence of misused namespaces.. right?

##### Share on other sites
If your namespaces do become somewhat unwieldy, try using namespace aliases.
namespace excessivly_long = std;excessivly_long::cout << "Lookit, it worked!!!\n";

Reverse example I admit, but still... you see what I mean.

##### Share on other sites
Quote:
 Original post by zoggoIf your namespaces do become somewhat unwieldy, try using namespace aliases.namespace excessivly_long = std;excessivly_long::cout << "Lookit, it worked!!!\n";Reverse example I admit, but still... you see what I mean.

yeah, i know how a namespace alias works, but you dont find it very weird to create a namespace alias for your own namespaces?

##### Share on other sites
I use namespaces to impose structure upon my madness. Almost like "code folders" really. Namespace aliases just allow me to bring, in a consise fashion, the code I want to access into scope without poluting the global namespace.

It doesn't appeal to everyone, but boost suggest it in preference to bringing the whole boost namespace into the global namespace.

##### Share on other sites
Nobody mentioned the biggest lameness of namespaces:

namespace test_space {enum test_enum{    test_enum_1,};};

Now if this is in a header, you either have to include the header everywhere to get the namespace, or re-declare the namespace/enum pair each time you use it in another header. THAT's a pain in the ass. It is a bit easier than using class-scope enums though.

Like most things in C++ yeah it's handy for some things. But it sucks for others.

##### Share on other sites
I prefer to keep the number of namespaces to a minimum. The library itself has a namespace of course. Within that, I would put additional namespaces to represent the boundaries between subsystems within that library. Eg, in my engine, I have three additional namespaces:

Scene
Resource
Renderer

They represent the boundaries between the three primary components of my engine (scene management, resource management, and rendering respecitively), and serve as both a form of self-documentation, and a system of compartmentalisation. These are the only additional namespaces in my engine library, as I feel they are the only significant distinct subsystems in the project. Smaller collections of related classes have thusfar been most logically expressed by making use of member classes, which adds an apparent third namespace layer in the cases where it is used.

I don't have a problem with large namespace trees for large systems, however I do not think that there should ever be a reason to navigate, say, 5 or 6 levels down a heirachy. I believe namespaces should represent boundaries between subsystems, and as such, namespaces within namespaces should in many cases contain a subset of functionality relevant to the parent namespace only, so in other words, only modules in namespaces that are either direct or close ancestors should be accessing nested namespaces. If the need arises to directly access functionality down deep namespace trees from much higher levels, I would say either there's a design problem, or the namespace heirachy has been ill-concieved.

A significant exception to this is best demonstrated in the .NET framework, where namespaces are used to categorise sets of inbuilt types, rather than manage the boundaries between interrelated components in a large system. It is a distinct and seperate application of namespaces, and it should be considered seperately. The goals are almost opposite.

Quote:
 Nobody mentioned the biggest lameness of namespaces:...source...Now if this is in a header, you either have to include the header everywhere to get the namespace, or re-declare the namespace/enum pair each time you use it in another header. THAT's a pain in the ass. It is a bit easier than using class-scope enums though.

I don't understand what you're getting at. Yes, you have to include that header everywhere you want test_enum to be available. How is this any different to anything else in C, and how are namespaces involved? If that enum wasn't wrapped in a namespace, you'd have the same problem.

##### Share on other sites
I don't use any namespaces for my libraries, relying on the class names to tell me what's going on. The 3rd party libraries I use don't do this either.

• 17
• 11
• 12
• 9
• 49
• ### Forum Statistics

• Total Topics
631394
• Total Posts
2999755
×