# An alternative to "namespaces"

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

## Recommended Posts

Here is the problem i've got:

Currently I have sever classes Named Node:

- one for the 3d scene importer/exporter

- one for the "current state" of an instance of an animated 3d scene.

- one for the editor

- any probably another one somewhere.

Currently I resolve these by using "local namespaaces aka:

namespace Scene3D { struct Node .. }
namespace EvaluateScene { struct Node ... }
namespace EditorUtils { struct Node ...}

This sure works, but i really do not like. To be honest I do not like namespaces at all. I really they do not work that wall in C++ (expecially when you try mising using <namespace> in the cpp with not using namespace in the header.
It just gets to messy because in the implementation of Scene3D im referring to the Node struct just by using "Node" but outside i use Scene3D::Node. And it gets even messier when I have to use Scene3D::Node in namespace EvaluateScene - it just get absoletley bananas.
Not to mention that forward declarations get messy too.

I'm thinking about switching to "prefixes" actually I resolve a few similar collisions in my code base like that, but the names are getting too long(but i think i prefer it).

nested classes/structs are not an option as they prevent me to forward declare.

Do you have the same problem?

How do you solve it?

Edited by imoogiBG

##### Share on other sites

Depends on what nodes are in your system , you can refactor it to a generic class in a common solution.

You may want to change the names to a specific job, for example instead of "Node" in your scene solution, you may call it "SceneNode" and then you'd know... it's a scene node.

Use proper logical structure. Maybe the seperation for "Scene3D", "EvaluateScene" and "EdtiorUtils" are not good and need some refactoring?

And why'd you need all nodes or some nodes in a function or a file? Maybe that's your problem, you are using too many things in 1 place.

##### Share on other sites

You may want to change the names to a specific job, for example instead of "Node" in your scene solution, you may call it "SceneNode" and then you'd know... it's a scene node.

Yeah, this. More general nouns are valuable lexical real-estate. Names such Node/Handle/Buffer/etc could be used by endless different systems, so it's almost selfish to use them. This is especially important when working in larger teams.

An alternative to using more descriptive names is extensive use of namespaces, so within each module you're free to use common/bland names.

I'm not a fan of namespaces either, so a middle ground is inner classes, such as std::vector<Foo>::iterator, or
struct QuadTreeTerrainRenderer {
Struct Node {...};
};

##### Share on other sites

Personally at the moment I use prefixes (and short descriptive names), for the same reasons you are suggesting .. writing too much 'faff' boilerplate code (you might end up using macros / tricks to reduce this).

But I think it depends what you are writing, if I were writing a library for others to use, I'd namespace everything, to prevent name conflicts and delineate code. And also when working with a team it can make sense to help prevent programmers stepping on each others toes.

It isn't such a massive task to refactor in / out namespaces, so I'm a big fan of going with what makes you more productive. :P Although I'm sure there are zealots who wouldn't write a 'hello world' without a namespace.

##### Share on other sites
Note that it is discouraged to use 'using namespace' in header files. You should also avoid using 'using namespace' in cpp files if you can substitute with 'namespace something{ }'.

##### Share on other sites

expecially when you try mising using <namespace> in the cpp with not using namespace in the header.

Seems like an issue learning to use C++ properly. This is in addition to using good names.

You shouldn't have "using namespace" in the header. That destroys the entire purpose. It invites the hordes to everyone who uses your module.

In a CPP file you generally shouldn't have "using namespace" either, preferring to rely on Koenig lookup to automatically find the items. Generally either use explicit names or a short list of "using name" statements rather than "using namespace" statements. The using statements invite entire systems directly into your module which usually isn't what you want. The exception is if you are working as part of the module, in which case you declare the entire block as being inside the namespace.

##### Share on other sites

You shouldn't have "using namespace" in the header. That destroys the entire purpose. It invites the hordes to everyone who uses your module.

I think OP knows that and his point was that he finds it messy to have to fully-qualify the names in headers, but not need to in the implementations.

To elaborate on what I've already said, my usual tactic is to have a single namespace for the project. That keeps name collisions from happening with other libraries, but I don't get lost in multiple nested namespaces and confused by multiple things having the same name. When I do use nested namespaces, I try not to nest namespaces more than 2 levels deep. Anything more than that and I find it gets confusing.

Another naming scheme I've seen before on big legacy projects is to have new code be in its own namespace to distinguish between the legacy code and the new code. Edited by Oberon_Command

##### Share on other sites

Honestly, it depends on how widely your code will be used.

If it's a small project with one developer, you can get away with minimal (or even no) namespaces.

At the other end of the scale, I've worked in scenarios where everything was in a Company::Product::Project::Domain namespace (e.g. SuperSoft::AwesomeGame::Engine::Renderer). This was because code was often shared between products and teams.

Elaborating on what @Hodgman said, only use generic names for generic concepts. If you have a Node class, then I'd expect that to work as a Node in a DOM, in a linked list, in a SceneTree.... whatever. If it's not that generic, then be more specific with the name.

On the flip side, lack of namespaces can result in Smurf Naming

1. 1
Rutin
23
2. 2
3. 3
JoeJ
20
4. 4
5. 5

• 29
• 40
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631740
• Total Posts
3001966
×