Using namespace considered bad?

[Calum Grant]

In older C++ computer books, you'll often see

using namespace std;

even in my 1996 copy of Stroustrup. Nowadays, it seems to be considered
better to qualify names to make it clearer what symbol you are using.
Are there any articles that support this viewpoint? Is "using
namespace" definitively wrong, or just a matter of style?

How about when implementing a library "foo", would it not make the code
so much clearer just to write "using namespace foo" at the top of the
source file to make the code much more readable?

Calum

 

[Rapscallion]

In older C++ computer books, you'll often see

using namespace std;

even in my 1996 copy of Stroustrup. Nowadays, it seems to be considered
better to qualify names to make it clearer what symbol you are using.
Are there any articles that support this viewpoint? Is "using
namespace" definitively wrong, or just a matter of style?

How about when implementing a library "foo", would it not make the code
so much clearer just to write "using namespace foo" at the top of the
source file to make the code much more readable?

Rule of thumb:
'using namespace whatever' in header files is bad because you pull in
the names of the namespace for all following (include) files (which
would defeat the purpose of the namespace).
'using namespace whatever' after all #include(s) in source files is ok
to "make the code much more readable".

R.C.

 

[Rolf Magnus]

In older C++ computer books, you'll often see

using namespace std;

even in my 1996 copy of Stroustrup. Nowadays, it seems to be considered
better to qualify names to make it clearer what symbol you are using.
Are there any articles that support this viewpoint? Is "using
namespace" definitively wrong, or just a matter of style?

How about when implementing a library "foo", would it not make the code
so much clearer just to write "using namespace foo" at the top of the
source file to make the code much more readable?

Depends. Consider having another library "bar" that defines a class with the
same name (say "list" e.g.). Within a file, you'd always have to look
somewhere else to find which list is actually meant.
Also, you cannot do

using namespace foo;
using namespace bar;

because that would lead to name clashes. namespaces basically serve two
purposes:

- organizing names into groups to make the code more understandable
- avoiding name clashes

"using namespace" tends to elide both advantages, basically making the whole
concept of namespaces useless. Therefore, I think it should actually be
"useless namespace" instead of "using namespace" ;-)

 

[Calum Grant]

Calum Grant wrote:




Depends. Consider having another library "bar" that defines a class with the
same name (say "list" e.g.). Within a file, you'd always have to look
somewhere else to find which list is actually meant.
Also, you cannot do

using namespace foo;
using namespace bar;

because that would lead to name clashes.

Yes, it's pretty helpful that names clash - it would be far worse if the
name silently resolved to one or the other.

I just don't see the problem. If there's a clash you get an error, and
if there is no clash, there is no problem. So if you get a clash, all
you need to do is qualify the name and it all works again.

namespaces basically serve two
purposes:

- organizing names into groups to make the code more understandable
- avoiding name clashes

"using namespace" tends to elide both advantages, basically making the whole
concept of namespaces useless. Therefore, I think it should actually be
"useless namespace" instead of "using namespace" ;-)

I can only relate my own experiences - I have regularly put "using
namespace mylib;" at the top of my .cpp files with very few bad effects.
Though now I am reevaluating this choice.

Is "using foo::list;" better than "using namespace foo;" ?

Calum

 

[Pete Becker]

Also, you cannot do

using namespace foo;
using namespace bar;

because that would lead to name clashes.

Only if you use them. <g> That is, if both foo and bar define 'list' but
you don't use that name there's no clash. If you try to use the name
'list' without a namespace qualifier it's ambiguous, so you have to
qualify it, either foo::list or bar::list.

 

[ma740988]

In older C++ computer books, you'll often see

using namespace std;

even in my 1996 copy of Stroustrup. Nowadays, it seems to be considered
better to qualify names to make it clearer what symbol you are using.
Are there any articles that support this viewpoint? Is "using
namespace" definitively wrong, or just a matter of style?

How about when implementing a library "foo", would it not make the code
so much clearer just to write "using namespace foo" at the top of the
source file to make the code much more readable?

Calum

I was advised against including the entire namespace in my header file.
Refer to this link:

http://groups-beta.google.com/group...f229?q=ma740988&rnum=1&hl=en#181244afdbfcf229


My issue is, I have a header file called common_header.h. Within
common_header.h I have


# include<iostream>
# include<vector>
# include<list>
# include<string>
# include<functional>
# include<algorithm>
# include<ctime>
// more


Now use common_header.h:

foo.h - # include "common_header.h"
bar.h - # include "common_header.h"
baz.h - # include "common_header.h"
// a few more


instead of:
using std::cout;
using std::endl;
using std::string;
// etc
in common_header. I might as well do 'using namespace std' in
common_header.

-----------------
Francis Glassborow replied with:

You make it impossible for anyone using that header to not use
namespace
std. What you do within your own implementation files is entirely your
choice but one of the major features of header files is to support
development being done by multiple programmers.


--- /////
In my implementation files have _no_ bearing on anyonelse. The notion
of having to qualify specific names was difficult for me to understand.
Admittidely, I'm curious to/will review 'namespace std'.

 

[Cy Edmunds]

In older C++ computer books, you'll often see

using namespace std;

even in my 1996 copy of Stroustrup. Nowadays, it seems to be considered
better to qualify names to make it clearer what symbol you are using. Are
there any articles that support this viewpoint? Is "using namespace"
definitively wrong, or just a matter of style?

How about when implementing a library "foo", would it not make the code so
much clearer just to write "using namespace foo" at the top of the source
file to make the code much more readable?

Calum

In a header file using "using" is a mistake. In a .cpp file I think you are
on your own. If you don't have any name clashes I don't see any serious
problem with a "using" clause.

Having said that, I rarely use "using". I think the argument that "using
namespace std;" saves typing is pretty dubious -- compared to the time it
takes to design and test good code, how much time is spent actually doing
the typing? I also don't like "using std::cout;" because it is
unmaintainable. I don't want my file to declare that I am using a specific
function if I am not, and I don't want to police this usage as the code is
refactored. (Of course the header files themselves pose a similar problem
but there is no way around that.) So I just write it out: "std::cout << x;".
Of course most people would recognize cout as being part of the standard
library, but the standard library is huge and getting even bigger, so unless
you sleep with a copy of Josuttis under your pillow every night you will
eventually encounter standard library names which are new to you. Finally,
when I am writing library code of my own, I refuse to put in long names to
avoid name conflicts such as cylib_dothis and cylib_dothat. I wrap
everything in a namespace and assume the client will consider the namespace
as part of the name: cylib::dothis and cylib::dothat.

Cy

 

[Markus Dehmann]

My issue is, I have a header file called common_header.h. Within
common_header.h I have


# include<iostream>
# include<vector>
# include<list>
# include<string>
# include<functional>
# include<algorithm>
# include<ctime>
// more


Now use common_header.h:

foo.h - # include "common_header.h"
bar.h - # include "common_header.h"
baz.h - # include "common_header.h"
// a few more


instead of:
using std::cout;
using std::endl;
using std::string;
// etc
in common_header. I might as well do 'using namespace std' in
common_header.

Isn't that considered bad as well? I mean having a project-level header file
and including it from everywhere? I mean baz.h might actually not need
ctime, but it still depends on it. It's very unlikely that foo.h, bar.h,
and baz.h all need exactly all the stuff that you have in common_header.h.
And it's always bad to include more than you need.

 

[Steven T. Hatton]

Depends. Consider having another library "bar" that defines a class with
the same name (say "list" e.g.). Within a file, you'd always have to look
somewhere else to find which list is actually meant.
Also, you cannot do

using namespace foo;
using namespace bar;

because that would lead to name clashes. namespaces basically serve two
purposes:

- organizing names into groups to make the code more understandable
- avoiding name clashes

"using namespace" tends to elide both advantages, basically making the
whole concept of namespaces useless. Therefore, I think it should actually
be "useless namespace" instead of "using namespace" ;-)

For the most part I agree with you. I have, however, encountered a reason
for invoking a using directive (as opposed to a using declaration). If I
have a math library that has a lot of different little operand and operator
classes that I want to work automagically, then it makes sense to have
"using namespace math" in the smallest enclosing block of code where it is
applicable. I might also do that if it's clear that the using declaration
will eliminate a lot of clutter in a particular function, or other
restricted block of code.

I have even resorted to using nameless brackets to limit the scope of such
using directives. That is:

void foo(){
//lots of code ...
{
using namespace bar;
//more code ...
}

// more code.
}

Typically, I prefer the using declaration over the using directive, and
often find it better to simply qualify the name. I recently came across
some code that had a using directive for the purpose of avoiding opening
the namespace for member function declarations. That is:
// in the header file:
namespace foo {
class Bar{
void baz();
}

// in the .cpp file:

using namespace foo;

void Bar::baz(){}

That is not good style, IMO.

 

[Steven T. Hatton]

Isn't that considered bad as well? I mean having a project-level header
file
and including it from everywhere? I mean baz.h might actually not need
ctime, but it still depends on it. It's very unlikely that foo.h, bar.h,
and baz.h all need exactly all the stuff that you have in common_header.h.
And it's always bad to include more than you need.

That really seems to depend on the situation, and who you ask. Josuttis and
Vandervoorde suggest that putting all the standard headers into one big
include file will reduce compile time (considerable) under many
circumstances. They don't limit that suggestion to the standard headers
either. The caveat I have to that is that I have hit some very strange
situations in which syntax errors in my code cause the compiler to detect
errors in header files from the libraries I'm using, and these errors are
sensitive to the order in which the header files are included into the
translation unit. No fun to untangle!

 

[ma740988]

Steven T. Hatton provided a response on where I 'stole' (Josuttis and
Vandervoorde) this approach.

 

[Donovan Rebbechi]

Yes, it's pretty helpful that names clash - it would be far worse if the
name silently resolved to one or the other.

I just don't see the problem. If there's a clash you get an error, and
if there is no clash, there is no problem. So if you get a clash, all
you need to do is qualify the name and it all works again.

There's also a readability issue -- where did all those names come from ?

Is the Foo class defined in library X or library Y ? Maybe you know, but it's
less clear to someone else reading the same code.

For this reason, I prefer the more explicit (but verbose)

using namespace::name;

form, so that it is clear to someone reading the code in question which
namespace a given name came from.

I can only relate my own experiences - I have regularly put "using
namespace mylib;" at the top of my .cpp files with very few bad effects.

It potentially makes your code less readable to others, but that's a non-issue
unless someone else has to read your code.

Though now I am reevaluating this choice.

Is "using foo::list;" better than "using namespace foo;" ?

Yes.

Cheers,

 

[ma740988]

So lets see if I could summarize this. using namespace std in a header
file is _for the most part_ (you might argue almost always) bad
pratice. Solutions:

1.
| So I just write it out: "std::cout << x;".

Ok!! This implies I'll qualify the items with std:: I could live
with this.

2.
| In a .cpp file I think you are on your own. If you don't have any
name clashes
| I don't see any serious problem with a "using" clause.

No 'serious problem with a using clause', hence what I'm left with here
is:

foo.h
# include <iostream>
# include <map>
// more
foo.cpp
# include "foo.h"
using namespace std; // <-

bar.h
# include <string>
bar.cpp
# include "bar.h"
using namespace std; // <-

Preferred if I plan to include the entire namepace. Except now it's
possible that I'll endu up doing this for all translation units.

3.
| I also don't like "using std::cout;" because it is unmaintainable.

foo.h
# include <iostream>
# include <map>
// more
foo.cpp
# include "foo.h"
using std::cout;
using std::map;
// etc

bar.h
# include <string>
bar.cpp
# include "bar.h"
using std::string;

View potentially as unmaintanable. I agree.