namespace MyEngine {
namespace Core {
class Pipeline() {}
}
}
MyEngine::Core::Pipeline* pPipeline = new MyEngine::Core::Pipeline();
to namespace or not to namespace?
Author
when does namespace partitioning become an overhead?
i personally like to use a deep namespace hierarchy when i'm coding, like
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::
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::
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.
Author
Quote:Original post by MonderQuote: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?
If your namespaces do become somewhat unwieldy, try using namespace aliases.
Reverse example I admit, but still... you see what I mean.
namespace excessivly_long = std;excessivly_long::cout << "Lookit, it worked!!!\n";Reverse example I admit, but still... you see what I mean.
Author
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?
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.
It doesn't appeal to everyone, but boost suggest it in preference to bringing the whole boost namespace into the global namespace.
Nobody mentioned the biggest lameness of namespaces:
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.
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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
