should "using namespace std" be used?

[Pep]

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify that
the std namespace is being used instead of tagging each member of the
namespace?

 

[Jim Langston]

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

For non trivial code, using std namespace; may be okay, but I never use it
then either.

The problem with using std namespace; is that it brings everything into the
unnamed namespace. Usually this doesn't cause problems, until you try to
declare a function or variable or class with the same name as something else
in the std namespace.

If you don't really like doing std::cout std::endl etc... just bring what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

 

[Pep]

For non trivial code, using std namespace; may be okay, but I never use it
then either.

The problem with using std namespace; is that it brings everything into
the
unnamed namespace. Usually this doesn't cause problems, until you try to
declare a function or variable or class with the same name as something
else in the std namespace.

This is where I dither over the choice. Given that all c++ programmers are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std and as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.

If you don't really like doing std::cout std::endl etc... just bring what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

Yet, as a new developer on a project that has been badly documented and laid
out over several hundred source files, I might miss the fact that cout and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

 

[Sumit Rajan]

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

This is covered in the FAQ:
http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.5

Regards,
Sumit.

 

[Pep]

This is covered in the FAQ:
http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.5

Regards,
Sumit.

Whilst I agree with the FAQ in a new project, it does not really address the
scenario I placed in my reply to Jim Langston. Yes it is possible to
decide at the begginning of a project but badly documented projects which I
have worked on do not make the distinction very clearly and when the long
time serving inmates of the project leave, they take that sort of knowledge
with them. In the past I have wasted 3 days on a simple bug simply because
it was not documented that some of the std entities had been replaced with
locally defined ones.

Then again maybe I should simply stick to contracts that involve properly
documented designs, yeah right

 

[Daniel T.]

This is covered in the FAQ:
http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.5

Whilst I agree with the FAQ in a new project, it does not really address the
scenario I placed in my reply to Jim Langston. Yes it is possible to
decide at the begginning of a project but badly documented projects which I
have worked on do not make the distinction very clearly and when the long
time serving inmates of the project leave, they take that sort of knowledge
with them. In the past I have wasted 3 days on a simple bug simply because
it was not documented that some of the std entities had been replaced with
locally defined ones.

Then again maybe I should simply stick to contracts that involve properly
documented designs, yeah right [/QUOTE]

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

The supposed "problem" of "using namespace std" allowing the compiler
see all the std names isn't a problem at all, and refusing to have using
declarations and directives in your code defeats the purpose of the
namespace mechanism.

See "C++ Coding Standards" by Sutter & Alexandrescu for a more
reasonable rule regarding the "using" keyword.

 

[Marcus Kwok]

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

 

[Pep]

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

Hmm, I tend to agree with this view. Adding "using namespace std" in source
files is fine as it is local to the coding point whereas adding to include
files can affect the project in ways not intended.

Then again it would be nice if just once when I join a project I find well
documented code with good design docs, just as of course I always do when
starting a new project

 

[Marcus Kwok]

Hmm, I tend to agree with this view. Adding "using namespace std" in source
files is fine as it is local to the coding point whereas adding to include
files can affect the project in ways not intended.

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migrating_to_namespaces.htm

 

[Richard Herring]

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migrating_to_namespaces.htm

where you'll find this gem:

"I find it helpful to think of a using directive as a marauding army of
crazed barbarians that sows indiscriminate destruction wherever it
passes"

 

[Howard]

This is where I dither over the choice. Given that all c++ programmers
are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std and
as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.


Yet, as a new developer on a project that has been badly documented and
laid
out over several hundred source files, I might miss the fact that cout and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

I don't find it particularly inconvient to type the extra characters for
things lke std::cout, so most of the time I just type it out.

But if I'm working with other developers, I'll often put using statements
(such as "using std::cout;") at the top of a given function. That way, the
using statements for that function are right there at the entry to the
function, where other developers can immediately see what the following code
is referring to. (Which is good self-documentation!)

-Howard

 

[mlimber]

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

The supposed "problem" of "using namespace std" allowing the compiler
see all the std names isn't a problem at all, and refusing to have using
declarations and directives in your code defeats the purpose of the
namespace mechanism.

See "C++ Coding Standards" by Sutter & Alexandrescu for a more
reasonable rule regarding the "using" keyword.

As Daniel T. notes, there are different schools of thought on the
matter. The rule from _C++ Coding Standards_, item 59 (italics in
original) is: "You can and should use namespace using declarations and
directives liberally /in your implementation files after #include
directives/ and feel good about it. Despite repeated assertions to the
contrary, namespace using declarations and directives are not evil and
they do not defeat the purposes of namespaces. Rather, they are what
make namespaces usable."

Cheers! --M

 

[Cy Edmunds]

I don't find it particularly inconvient to type the extra characters for
things lke std::cout, so most of the time I just type it out.

But if I'm working with other developers, I'll often put using statements
(such as "using std::cout;") at the top of a given function. That way,
the using statements for that function are right there at the entry to the
function, where other developers can immediately see what the following
code is referring to. (Which is good self-documentation!)

-Howard

I agree that it is good documentation, but I find it hard to maintain. If
you refactor your code in such a way that the function is no longer used you
have to remember to get rid of your using clause also. Of course it is not
an error to claim to be using something you are not, but it is misleading.

Cy

 

[Cy Edmunds]

Whilst I agree with the FAQ in a new project, it does not really address
the
scenario I placed in my reply to Jim Langston. Yes it is possible to
decide at the begginning of a project but badly documented projects which
I
have worked on do not make the distinction very clearly and when the long
time serving inmates of the project leave, they take that sort of
knowledge
with them. In the past I have wasted 3 days on a simple bug simply
because
it was not documented that some of the std entities had been replaced
with
locally defined ones.

Then again maybe I should simply stick to contracts that involve properly
documented designs, yeah right

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

The supposed "problem" of "using namespace std" allowing the compiler
see all the std names isn't a problem at all,[/QUOTE]

I don't think you have thought this through. What happens when a revised
standard comes out and the standard namespace gets another large injections
of names? For that matter, what happens when you refactor your own code and
introduce a symbol which conflicts with a standard identifier?
Maintainability is too important to compromise for the sake of avoiding
typing std:: in front of a few symbols.

and refusing to have using

declarations and directives in your code defeats the purpose of the
namespace mechanism.

You must be kidding. It is "using namespace std;" which defeats the purpose
of the namespace mechanism!

 

[Cy Edmunds]

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migrating_to_namespaces.htm

From the cited article:

In short, a good long-term solution for namespace usage should follow at
least these rules:

Namespace Rule #1: Avoid using directives entirely, especially in header
files.

The part of the article recommending using clauses has to do with updating
legacy code. This is a lot different than "Adding "using namespace std" in
source files is fine...".

 

[Derek]

Is it best to include the code "using namespace std;" in the source

Yes.

The argument that you want to avoid namespace conflict is a very weak
one.

The only time you wouldn't want to include "using namespace std;" is
when you are writing code that makes absolutely no use of standard c++
namespace objects.

 

[Daniel T.]

I don't think you have thought this through. What happens when a revised
standard comes out and the standard namespace gets another large injections
of names? For that matter, what happens when you refactor your own code and
introduce a symbol which conflicts with a standard identifier?

The compiler informs me of the issue and I disambiguate the code.

Maintainability is too important to compromise for the sake of avoiding
typing std:: in front of a few symbols.

That is exactly why I think putting std:: in front of all the symbols is
a bad idea. Pre-namespace, each library had to prepend every function
and type in its code with some "unique" symbol, this had to be typed
every-time one used any type or symbol from that library.

The whole point of the namespace mechanism is to remove the need for
those warts, so why on earth would you voluntarily put them right back
in again?

You must be kidding. It is "using namespace std;" which defeats the purpose
of the namespace mechanism!

As I show above, I'm not kidding.

 

[Daniel T.]

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

I had started to word it much like you did, so I guess we are on the
same page.

 

[Daniel T.]

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migrating_to_namespaces.htm

Mr. Sutter later revised his opinion on this matter, which is why I
explicitly referenced his recent book.

 

[Cy Edmunds]

The compiler informs me of the issue and I disambiguate the code.


That is exactly why I think putting std:: in front of all the symbols is
a bad idea. Pre-namespace, each library had to prepend every function
and type in its code with some "unique" symbol, this had to be typed
every-time one used any type or symbol from that library.

The whole point of the namespace mechanism is to remove the need for
those warts,

I think the point is to give the programmer a reasonable way to avoid name
collisions. Namespaces only remove warts if you take the unsafe appoach of
automatically placing a using clause at the top of each of your programs.
Doing this is the functional equivalent of using neither warts nor
namespaces.

so why on earth would you voluntarily put them right back

in again?

In old fashioned C interfaces we had to put warts on the names to prevent
collisions. For instance:

mylib_open();
mylib_close();

As you point out, it isn't a great step forward to have to type

mylib:pen();
mylib::close();

However, there was never a practice of writing

std_vector<double> x;
std_cout << y;

Hence, putting potentially hundreds of names in your namespace by writing

using namespace std;

seems kind of crazy, at least for new code. (I could see it as a measure for
migrating legacy code.) In effect, namespaces allow us to put warts on all
the standard library names which, given their sheer number, seems like a
damned good idea to me.

I personally don't mind writing

mylib:pen();

That, together with a telling header such as

#include "mylib/mylib.h"

gives the reader of the code a pretty good idea of where things are coming
from. And if the namespace is too long there is a mechanism to create an
alias.

As I show above, I'm not kidding.

Now I understand the disconnect: we have radically different ideas about the
purpose of namespaces.