Sign in to follow this  
Metus

to namespace or not to namespace?

Recommended Posts

Metus    168
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 this post


Link to post
Share on other sites
cozman    583
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 this post


Link to post
Share on other sites
Monder    993
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 this post


Link to post
Share on other sites
Metus    168
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;

instead of

Pipeline* pPipeline = new Pipeline;


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

Share this post


Link to post
Share on other sites
zoggo    194
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 this post


Link to post
Share on other sites
Metus    168
Quote:
Original post by zoggo
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.


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 this post


Link to post
Share on other sites
zoggo    194
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 this post


Link to post
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 this post


Link to post
Share on other sites
Nemesis2k2    1045
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 this post


Link to post
Share on other sites
Basiror    241
i use namespaces a lot in libraries, why? because i like to know what piece of code i am currently using on the first view without having to browse through headerfiles

thats why i keep namespace names pretty short and usually use only 2 levels

i personally like to encapsulate every piece of code i write into a library for later reuse, this shall reduce the development time of my projects by ways on the long term and in conjunction with a decent IDE that can do namespace browsing like the VC IDEs this saves another huge amount of time

no more browsing of a huge global namespace with tons of entries


so in a few words, i use them for clean code and reduced production times

Share this post


Link to post
Share on other sites
SiCrane    11839
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.


Aside from possibly negatively affecting the performance of dynamic_cast and/or adding bloat for RTTI structures.

Share this post


Link to post
Share on other sites
Monder    993
Quote:

Aside from possibly negatively affecting the performance of dynamic_cast and/or adding bloat for RTTI structures.


I stand corrected, thanks for pointing that out. Though if such penalties did occur I doubt they'd have much of an impact.

Share this post


Link to post
Share on other sites
Deyja    920
They only expand the textual representation of the types name, which is a minor additional bit of memory per class, not per instance. The name is mangled into a single globally unigue identifier that includes all the namespace names and template parameters but not a single colon.

Share this post


Link to post
Share on other sites
SiCrane    11839
Quote:
Original post by Deyja
They only expand the textual representation of the types name, which is a minor additional bit of memory per class, not per instance. The name is mangled into a single globally unigue identifier that includes all the namespace names and template parameters but not a single colon.

What you describe is an implentation specific behavior. Compilers other than yours may work differently. For example, an implementation is free to stick the colons into the string returned when you call std::type_info::name(), or even store the colons internally to do string match ups in dynamic_casts.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this