Back to General and Gameplay Programming

An alternative to "namespaces"

General and Gameplay Programming Programming

Started by ongamex92 October 14, 2016 10:18 PM

10 comments, last by _Silence_ 7 years, 6 months ago

ongamex92

3,287

Author

October 14, 2016 10:18 PM

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?

Oberon_Command

6,371

October 14, 2016 10:32 PM

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

What problem are you having with this?

How do you solve it?

I don't spam my codebase with classes that all have the same name. A namespace should represent a logical grouping of functionality. Just because you can use a namespace to distinguish between things that have the same name, doesn't mean that's its primary utility.

If you're using namespaces to group functionality that belongs together, and you find yourself doing "messy" cross-namespace references, then the messiness is a good thing - it's a code smell that you might not otherwise get. "Messiness" can sometimes be a sign that the way you have organized your code base may need some rethinking.

Nypyren

12,313

October 14, 2016 10:36 PM

Maybe the name "Node" itself isn't descriptive enough and should be refactored to be use-specific in each location?

I can't look at Scene3D::Node OR SceneNode and know what that means. What is a node in that context? Name it that.

Usually when you name things with good names, they won't collide even if everything's in the same namespace (except maybe when dealing with third party libraries).

WoopsASword

963

October 15, 2016 02:54 AM

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.

Hodgman

52,717

October 15, 2016 03:31 AM

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 {...};
};

. 22 Racing Series .

lawnjelly

2,021

October 15, 2016 08:30 AM

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.

Ivorne

485

October 16, 2016 01:55 PM

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{ }'.

frob

46,221

October 16, 2016 02:57 PM

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.

Oberon_Command

6,371

October 16, 2016 04:19 PM

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.

ChaosEngine

5,385

October 16, 2016 09:56 PM

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

if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

An alternative to "namespaces"

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

An alternative to "namespaces"

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines