By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,693 Members | 1,132 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,693 IT Pros & Developers. It's quick & easy.

Best practice for 'using namespaces'

P: n/a
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::part1::Class1; using project::part2::Class2;

3) namespace p1=project::part1;

4) prepend everything with project::part2::

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::part2:: 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

--
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!
Jun 23 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"Daniel Kraft" <d@domob.euwrote in message
news:f5**********@newsreader2.utanet.at...
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::part1::Class1; using project::part2::Class2;

3) namespace p1=project::part1;

4) prepend everything with project::part2::

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::part2:: 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.
Jun 23 '07 #2

P: n/a
On 23 Jun, 11:13, Daniel Kraft <d...@domob.euwrote:
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::part1::Class1; using project::part2::Class2;

3) namespace p1=project::part1;

4) prepend everything with project::part2::

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::part2:: 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::part2:: 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

Jun 23 '07 #3

P: n/a
>1) using namespace project; using namespace part1; using namespace part2;
>>
2) using project::part1::Class1; using project::part2::Class2;

3) namespace p1=project::part1;

4) prepend everything with project::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
--
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress --
so please use good, old E-MAIL!
Jun 23 '07 #4

P: n/a
On Sat, 23 Jun 2007 10:13:14 +0000, Daniel Kraft <d@domob.euwrote:
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::part1::Class1; using project::part2::Class2;
3) namespace p1=project::part1;
4) prepend everything with project::part2::
....
So only 4) seems to leave everything without impact, except that I do
not really want to type project::part2:: 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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!
Jun 24 '07 #5

P: n/a
On Jun 24, 10:09 pm, Jorgen Grahn <grahn+n...@snipabacken.dyndns.org>
wrote:
On Sat, 23 Jun 2007 10:13:14 +0000, Daniel Kraft <d...@domob.euwrote:
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::part1::Class1; using project::part2::Class2;
3) namespace p1=project::part1;
4) prepend everything with project::part2::
...
So only 4) seems to leave everything without impact, except that I do
not really want to type project::part2:: 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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!
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).

Jun 24 '07 #6

P: n/a
On 24 Jun, 23:59, comp.lang.super...@gmail.com wrote:
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/com...a567584efd7815

Gavin Deane

Jun 25 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.