should "using namespace std" be used?

[Pep]

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

Agreed that this is a reasonable approach that I have adopted in the past
but I think my problems with the namespaces are that I invariably get
drafted in to radically upgrade and support really bad legacy code which
has routines that extend to over 1,000 lines of code in one single method,
I kid you not!

The current project I am maintaining has hundreds of routines like this,
sometimes multiple > 1,000 lines of code per method in one source file!

So at this point you can forgive developers for not noticing anything at the
top of the routine, which in this case I suppose the only safe option is to
either

use the namespace std:: prefix to all enclosed routines

or

insist that std:: namespace is the default for the project and that any
routines, templates or classes used from other namespaces that override the
std:: namespace must be prefixed with the namespace tag

I guess this is going to become one of those legacy support issues when c++
is advanced to something new

 

[Pep]

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

It can be hard to maintain but no more than refactoring a deprecated class
such as ostrstream for ostringstream, in both cases you have to find all
occurrences of the item being refactored.

Thanks to everyone for their input on this. I guess it is as most things in
the real world, there are many ways of handling problems each with their
own pros and cons and supporters and detractors

 

[Daniel T.]

[snip]

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.
[snip]

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

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

 

[Marcus Kwok]

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

Oh ok, thanks for the info. I will check it out sometime.

 

[Cy Edmunds]

[snip]

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.
[snip]

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

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

Cy

 

[Daniel T.]

[snip]

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.
[snip]

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

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

 

[Jim Langston]

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.

Personally, I never use the using statement at all. I always just prefix
std:: as I don't find it that difficult at all. Of course typing 70+ wpm
helps. I find that not using using at all means I never have to worry about
what I'm bringing into the unnamed namespace and never get the hard to find
problems that others run into.

I used to program in C and I had run into the problem of two different
modules using the same function names and it was a pain to deal with. I
wound up hacking one of the modules renaming the functions everywhere. I
was overjoyed to find that C++ has namespaces to get rid of this problem,
and seeing how it's something that's extremely useful I'm going to do
everything I can to make sure I don't short circuit it, which I see as the
using statement as doing.

 

[Cy Edmunds]

[snip]
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.

[snip]

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

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the
using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

So you think the committee put namespaces into the language because they are
stupid? Name conflicts are a common problem in large projects.

The problem which doesn't exist is having to type std:: once in a while.

Cy

 

[Daniel T.]

[snip]
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.

[snip]

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

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the
using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

So you think the committee put namespaces into the language because they are
stupid? Name conflicts are a common problem in large projects.

No, I think they put the namespace mechanism into the language so that
library venders wouldn't have to make every-one put warts at the
beginning of all the types used in a program. I explained this already.

The problem which doesn't exist is having to type std:: once in a while.

Well, I guess that depends on how extensively you use standard
components and libraries that actually are in namespaces. If you are
only prepending the namespace "once in a while" I agree with you
completely

 

[Markus Schoder]

[snip]
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.

[snip]

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

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

[snip]

"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

So you think the committee put namespaces into the language because they
are stupid? Name conflicts are a common problem in large projects.

The problem which doesn't exist is having to type std:: once in a while.

You seem to miss the point. On the rare occasion were you hit a name
conflict you can use explicit scope resolution to resolve it. This is what
you cannot not do without namespaces.

There is still the risk that new names are introduced in namespace std in
the new standard conflicting with a heavily used name in your project.

I consider this risk however to be fairly small since new names will very
likely be mostly introduced through new header files thus not affecting
existing code.

 

[Bo Persson]

There is still the risk that new names are introduced in namespace
std in
the new standard conflicting with a heavily used name in your
project.

I consider this risk however to be fairly small since new names will
very
likely be mostly introduced through new header files thus not
affecting
existing code.

Right now new features are being added to existing headers in the
draft for the next standard. New features in their own headers, like
type_traits, are likely to be used by other parts of the standard
library, thus included indirectly.

I consider the risk to be fairly LARGE.


Bo Persson