Best practice for 'using namespaces'

[Jim Langston]

Hi all,

in my C++ projects, I usually make "heavy use" of namespaces to
"encapsulate" my code. When I have for instance something like this:

namespace project
{
namespace part1 { ... }
namespace part2 { ... }
}

And I want to use this somewhere else, there seem to be four
possibilities:

1) using namespace project; using namespace part1; using namespace part2;

2) using project:art1::Class1; using project:art2::Class2;

3) namespace p1=project:art1;

4) prepend everything with project:art2::

When I'm writing a cpp-file, I usually find myself using 1) -- I think
this is not really good, but as I'm affecting only my own code therein, it
shouldn't be too bad.

But what to do for a header-file which might be included by someone else?
1) and 2) bring things into his namespace he does not want, and even 3)
introduces a namespace-shortcut he does not need.

So only 4) seems to leave everything without impact, except that I do not
really want to type project:art2:: every time and at least to my taste
this makes the code more unreadable.

What are best practices for this problem, if there are any? Or what would
you suggest to do?

In my own code I don't make heavy use of namespaces, but I do use a
namespace around my utility header (std::string trim funciton, stream
converstion, etc...) and I just used a small name for the namespace: jml
(which happen to be my initials). so I go with 4.

Now, project::this project::that does seem to be a lot of typing, maybe you
could do a 5)

#define prj project
then just have to do
prj::this prj::that ?
I would presume that most namespace names would be rather largers (such as
boost: so a 3 letter shortcut shouldn't hurt you.

 

[Gavin Deane]

Hi all,

in my C++ projects, I usually make "heavy use" of namespaces to
"encapsulate" my code. When I have for instance something like this:

namespace project
{
namespace part1 { ... }
namespace part2 { ... }

}

And I want to use this somewhere else, there seem to be four possibilities:

1) using namespace project; using namespace part1; using namespace part2;

2) using project:art1::Class1; using project:art2::Class2;

3) namespace p1=project:art1;

4) prepend everything with project:art2::

When I'm writing a cpp-file, I usually find myself using 1) -- I think
this is not really good, but as I'm affecting only my own code therein,
it shouldn't be too bad.

But what to do for a header-file which might be included by someone
else? 1) and 2) bring things into his namespace he does not want, and
even 3) introduces a namespace-shortcut he does not need.

So only 4) seems to leave everything without impact, except that I do
not really want to type project:art2:: every time and at least to my
taste this makes the code more unreadable.

What are best practices for this problem, if there are any? Or what
would you suggest to do?

Within your own source files, as long as you understand the costs as
well as the benefits, any of 1, 2, 3 and 4 are fine. It's your code so
it's up to you. Personally, I use all 4 at one time or another (well,
maybe not number 3 very much, but that's just a personal preference).

In a header, the best practice advice is *never* to use 1 or 2 for
exactly the reason you suggest. I've not seen 3 discussed either way
very much (probably because, while misuse of "using namespace std" is
a common issue for beginners, namespace aliases aren't) but I would be
inclined to avoid it, again for the reason you suggest. Personally I
only ever use 4 in a header, but it sounds like you might be facing
longer fully-qualified names than I am. I tend to keep namespace names
relatively short specifically to reduce the impact on readability when
I use fully qualified names.

Your concern about readability is valid. Your concern about how long
it takes to type project:art2:: every time is *not*. Code is written
once but read many, many times. Therefore, while it may be worth the
cost of introducing a namespace alias if it means that every time
someone reads the code they are able to understand it more easily and
are less likely to be confused, it is unlikely to be worth the cost
solely to save you the one-off burden of a bit of extra typing (or
copy and pasting).

Gavin Deane

 

[Daniel Kraft]

Hi all,

in my C++ projects, I usually make "heavy use" of namespaces to
"encapsulate" my code. When I have for instance something like this:

namespace project
{
namespace part1 { ... }
namespace part2 { ... }
}

And I want to use this somewhere else, there seem to be four possibilities:

1) using namespace project; using namespace part1; using namespace part2;

2) using project:art1::Class1; using project:art2::Class2;

3) namespace p1=project:art1;

4) prepend everything with project:art2::

When I'm writing a cpp-file, I usually find myself using 1) -- I think
this is not really good, but as I'm affecting only my own code therein,
it shouldn't be too bad.

But what to do for a header-file which might be included by someone
else? 1) and 2) bring things into his namespace he does not want, and
even 3) introduces a namespace-shortcut he does not need.

So only 4) seems to leave everything without impact, except that I do
not really want to type project:art2:: every time and at least to my
taste this makes the code more unreadable.

What are best practices for this problem, if there are any? Or what
would you suggest to do?

Cheers,
Daniel Kraft

 

[Daniel Kraft]

1) using namespace project; using namespace part1; using namespace part2;

>
Now, project::this project::that does seem to be a lot of typing, maybe you
could do a 5)

#define prj project
then just have to do
prj::this prj::that ?
I would presume that most namespace names would be rather largers (such as
boost: so a 3 letter shortcut shouldn't hurt you.

....which looks to me nearly the same as 3, isn't it? Except that I
could do a #undef at the end of my header, but I believe this would turn
things a litte upside-down.

And I think
#define prj something
would be even worse in a header than
namespace prj=something,
as this would hurt for instance any variable prj or the like someone
might use whereas the namespace alias does not, right?

Yours,
Daniel

 

[Jorgen Grahn]

Hi all,

in my C++ projects, I usually make "heavy use" of namespaces to
"encapsulate" my code. When I have for instance something like this: ....
1) using namespace project; using namespace part1; using namespace part2;
2) using project:art1::Class1; using project:art2::Class2;
3) namespace p1=project:art1;
4) prepend everything with project:art2:: ....
So only 4) seems to leave everything without impact, except that I do
not really want to type project:art2:: every time and at least to my
taste this makes the code more unreadable.

Try 4) some time. You may (depending on what the code does and what
the interface looks like) find that you have to spell out the
namespace name much more rarely than you originally thought.

/Jorgen

 

[comp.lang.superman]

Try 4) some time. You may (depending on what the code does and what
the interface looks like) find that you have to spell out the
namespace name much more rarely than you originally thought.

/Jorgen

In 'The Design and Evolution of C++' Bjarne mentions that the using-
directives (like using namespace std should only be used for
transition programs. The newer programs should either use using-
declarations or explicit qualification (using scope-resolution, like
std::cout).

 

[Gavin Deane]

In 'The Design and Evolution of C++' Bjarne mentions that the using-
directives (like using namespace std should only be used for
transition programs. The newer programs should either use using-
declarations or explicit qualification (using scope-resolution, like
std::cout).

Please don't quote signatures. Thanks.

I don't know how Stroustrup feels about using directives these days,
but that advice is far from universally accepted any more. In "C++
Coding Standards", Sutter and Alexandrescu recommend in favour of
using directives. See this thread which refers to and quotes from the
book. And once you've done that, see the actual book

http://groups.google.co.uk/group/co...tter"+namespace&rnum=2&hl=en#b3a567584efd7815

Gavin Deane