Using nested namespaces

[Jaco Naude]

Hi

I'm using a top level namespace for a project. The project has a few
libraries which each have their own namespace. Each library has some
constants and interfaces defined under seperate namespaces as well.

For examples, for two different libraries the following namespaces are
present

ProjectNamespace::Library1
ProjectNamespace::Library1::Constants
ProjectNamespace::Library1::Interfaces
ProjectNamespace::Library2
ProjectNamespace::Library2::Constants
ProjectNamespace::Library2::Interfaces

I'm looking for for a way to include all the namespaces in a library
in one go, thus rather than adding the following:

using namespace ProjectNamespace::Library1;
using namespace ProjectNamespace::Library1::Constants;
using namespace ProjectNamespace::Library1::Interfaces;

I want to do the above in one line. Is that possible?

Any help would be appreciated.

Thanks,
Jaco

 

[Öö Tiib]

Hi

I'm using a top level namespace for a project. The project has a few
libraries which each have their own namespace. Each library has some
constants and interfaces defined under seperate namespaces as well.

For examples, for two different libraries the following namespaces are
present

ProjectNamespace::Library1
ProjectNamespace::Library1::Constants
ProjectNamespace::Library1::Interfaces
ProjectNamespace::Library2
ProjectNamespace::Library2::Constants
ProjectNamespace::Library2::Interfaces

I'm looking for for a way to include all the namespaces in a library
in one go, thus rather than adding the following:

using namespace ProjectNamespace::Library1;
using namespace ProjectNamespace::Library1::Constants;
using namespace ProjectNamespace::Library1::Interfaces;

I want to do the above in one line. Is that possible?

Any help would be appreciated.

Can you tell why you want to hide dependencies? Having dependencies
under control is important part of designing work.

In lousy design no one keeps track of dependencies so the list gets
long and boring to read. That leads to techniques of shortening it
like "main header file of include everything". Everything available
everywhere leads to further bad design over time (god objects,
spaghetti code).

So what i wanted to say was that you maybe do not cure disease there
but make it worse. Disease advances from "too lot of dependencies" to
"too lot of *hidden* dependencies".

 

[Gennaro Prota]

Hi

I'm using a top level namespace for a project. The project has a few
libraries which each have their own namespace. Each library has some
constants and interfaces defined under seperate namespaces as well.

Before going on... why?

 

[Jorgen Grahn]

Before going on... why?

Why indeed. So the next and more interesting question is: what is a
good use of namespaces within a project?

I'd drop the top-level namespace because I don't see its purpose, and
I'd drop Constants and Interfaces because ... well, I cannot explain
exactly why.

/Jorgen

 

[Gennaro Prota]

Why indeed. So the next and more interesting question is: what is a
good use of namespaces within a project?

I'd drop the top-level namespace because I don't see its purpose, and
I'd drop Constants and Interfaces because ... well, I cannot explain
exactly why.

I don't know if you are trying to be witty. I wouldn't drop the
top-level namespace but why would one want the two further
"subdivisions"?

 

[Öö Tiib]

Why indeed. So the next and more interesting question is: what is a
good use of namespaces within a project?

I'd drop the top-level namespace because I don't see its purpose, and
I'd drop Constants and Interfaces because ... well, I cannot explain
exactly why.

Project namespace is good idea. Typically a software project fails
(80% or so). Usually it has zero good lines of code in it too and that
makes it harder to reuse it in some other solution.

Libraries or modules that do something useful are rare and deserve
their own namespace. Like "useful" or "good" or "boost". However if
it is a project-specific library then put it into project namespace,
it likely does something useless and name tag of bad failed project on
it hopefully blocks a bit its spreading.

Logical further subnamespacing after library or module go by purpose
like submodule that does one thing and sublibrary that does other
thing.

About "constants" there might be is for example template<int=0x1D1O7>
constants class to achieve header-only external linkage for
constants.

About "interfaces" it may mean anything. If these mean "External" or
"Pure Abstract Base Classes" then yes drop that. Library namespace
itself is best place for its external interfaces. Some may want to put
module-internal things into some "internal" namespaces, but that is
often useless since it adds just code and blocks nothing. If it is
possible then just keep internal stuff out of reach for external
parties.

 

[Juha Nieminen]

I don't know if you are trying to be witty. I wouldn't drop the
top-level namespace but why would one want the two further
"subdivisions"?

I sometimes use nested namespaces for things like compile-time game
settings and such. I *could* use constant naming conventions instead,
but the nested namespaces allow for simpler names to be used inside
the namespaces themselves, besides giving a more logical division of
settings via the namespace blocks.

So I could have things like:

// In a file like settings_normal_mode.hh
namespace Settings
{
namespace NormalMode
{
const LevelSettings kLevelSettings[] =
{
...
};
}
}

// In a file like settings_bonus_levels.hh
namespace Settings
{
namespace BonusLevels
{
const LevelSettings kLevelSettings[] =
{
....
};
}
}

Then in the actual code that uses those settings I usually use full
names like "Settings::NormalMode::kLevelSettings" and so on.

As said, it could all be inside the 'Settings' namespace and the
different types of settings distinguished by a naming convention akin
to the inner namespaces, but doing it like that makes some things simpler
(besides allowing, if there really is a need, to pull things from such a
namespace into another, shortening the names).

It's a matter of taste, really.

 

[James Kanze]

I don't know if you are trying to be witty. I wouldn't drop
the top-level namespace but why would one want the two further
"subdivisions"?

If the project is a large library, you'll probably want to
divide it into subsystems, each with its own namespace. While
keeping the entire library in its own namespace for third party
users. And in a subsystem, it's not rare to want a private
namespace. So you could end up with something like:
Gabi::Text::UTF8::RegularExpressionPrivate
(All of my library is in Gabi, the text utilities in Text.
There are two versions of the text utilities, however: UTF-8 and
SingleByte. And then, RegularExpression is complicated enough
that it needs some members in a private namespace.)

 

[Jorgen Grahn]

I don't know if you are trying to be witty.

Does it matter? I was trying to be witty, but of course I meant what I
wrote, too.

I wouldn't drop the
top-level namespace

If it's a self-contained project (not a library) I see no point with a
top-level namespace. It smells like overengineering.

but why would one want the two further
"subdivisions"?

It feels strange to group things by their "type" (constant,
interface). And even stranger to do that, and then in a sense undoing
that work it by "using" in the calling code.

/Jorgen

 

[Gennaro Prota]

It feels strange to group things by their "type" (constant,
interface). And even stranger to do that, and then in a sense undoing
that work it by "using" in the calling code.

At last! We got there.