Why is 'using namespace std;' considered a bad practice in C++?

Question

Okay, sorry for the simplistic question, but this has been bugging me ever since I finished high school C++ last year. I've been told by others on numerous occasions that my teacher was wrong in saying that we should have "using namespace std;" in our programs, and that std::cout and std::cin are more proper. However, they would always be vague as to why this is a bad practice.

So, I'm asking now: Why is "using namespace std;" considered bad? Is it really that inefficient, or risk declaring ambiguous vars(variables that share the same name as a function in std namespace) that much? Or does this impact program performance noticeably as you get into writing larger applications?

I'm sorry if this is something I should have googled to solve; I figured it would be nice to have this question on here regardless in case anyone else was wondering.

Answer 1

IMHO, It's not bad.
Some people prefer to use it, but some (as I) not.

Answer 2

The only reason I can think of is surprise.

If I see cout << blah, instead of std::cout << blah

I think what is this 'cout'? Is it the normal cout? Is it somethign special?

Answer 3

This is not related to performance at all. But consider this: You are using two libraries called Foo and Bar:

using namespace foo;
using namespace bar;

Everything works fine, you can call Blah() from Foo and Quux() from Bar without problems. But one day you upgrade to a new version of Foo 2.0, which now offers a function called Quux(). Now you've got a conflict: Both Foo 2.0 and Bar import Quux() into your global namespace. This is going to take some effort to fix, especially if the function parameters happen to match.

If you have used foo::Blah() and bar::Quux() then the introduction of foo::Quux() would have been a non-event.

Answer 4

It's all about managing complexity. Using the namespace will pull things in that you don't want, and thus possibly make it harder to debug (I say possibly). Using sdt:: all over the place is harder to read (more text and all that).

Horses for courses - manage your complexity how you best can and feel able.

Answer 5

It depends on where it is located. If it is a common header, then you are diminishing the value of the namespace by merging the into the global. Keep in mind, this could be a neat way of making module globals.

Answer 6

Consider

// myHeader.h
using <sstream>
using namespace std;


// someoneElses.cpp/h
#include "myHeader.h"

class stringstream {  // uh oh
};

Note that this is a simple example, if you have files with 20 includes and other imports you'll have a ton of dependencies to go through to figure out the problem. The worse thing about it is that you can get unrelated errors in other modules depending on the definitions that conflict.

It's not horrible but you'll save yourself headaches by not using it in header files or the global namespace. It's probably alright to do it in very limited scopes but I've never had a problem typing the extra 5 characters to clarify where my functions are coming from.

Answer 7

I think it's bad to put it in the header files of your classes: because then you would be forcing anyone who wants to use your classes (by including your header files) to also be 'using' (i.e. seeing everything in) those other namespaces.

However, you may feel free to put a using statement in your (private) *.cpp files.

Answer 8

If you import the right header files you suddenly have names like hex, left, plus or count in your global scope. This might be surprising if you are not aware that std:: contains these names. If you also try to use these names locally it can lead to quite some confusion.

If all the STL stuff is in it's own namespace you don't have to worry about name collisions with your code or other libraries.

Answer 9

I do not think it is necessarily bad practice under all conditions, but you need to be careful when you use it. If you're writing a library, you probably should use the scope resolution operators with the namespace to keep your library from butting heads with other libraries. For application level code, I don't see anything wrong with it.

Answer 10

1. you need to be able to read code written by people who have different style and best practices opinions than you.

2. If you're only using cout, nobody gets confused. But when you have lots of namespaces flying around and you see this class and you aren't exactly sure what it does, having the namespace explicit acts as a comment of sorts. You can see at first glance, 'oh, this is a filesystem operation' or 'thats doing network stuff'.

Answer 11

I agree with everything Greg wrote, but I'd like to add: It can even get worse than this! Foo 2.0 could introduce a function Quux() that is an unambiguously better match for some of your calls too Quux() than the bar::Quux() your code called for years. Then your code still compiles, but silently calls the wrong function and does god-knows-what. That's about as bad as things can get.

Keep in mind that the std namespace has tons of identifiers, many of which are very common ones (think list, sort, string, iterator etc.) which are very likely to appear in other code, too.

---

Here's one more data point: Many, many years ago, I also used to find it annoying having to prefix everything from the standard library with std::. Then I worked in a project where it was decided at the start that both using directives and declarations are banned except for function scopes. Guess what? It took most of us very few weeks to get to used to write the prefix and after a few more weeks most of us even agreed that it actually made the code more readable. (There's a reason for that: Whether you like shorter or longer prose is subjective, but the prefixes objectively add clarity to the code. Not only the compiler, but you, too, find it easier to see which identifier is referred to.)

In almost a decade, that project grew to have several million lines of code. Since these discussions comes up again and again, I once was curious how often the (allowed) function-scope using actually was used in the project. I grep'd the sources for it and only found one or two dozen places where it was used. To me this indicates that, once tried, developers didn't find std:: painful enough to employ using directives even once every 100kLoC even where it was allowed to be used.

---

Bottom line: Explicitly prefixing everything doesn't do any harm, takes very little getting used to, and has objective advantages. In particular, it makes the code easier to interpret by the compiler and by human readers - and that should probably be the main goal when writing code.

Answer 12

I also consider it a bad practice. Why? Just one day I thought that function of a namespace is to divide stuff so I shouldn't spoil it with throwing everything into one global bag. However, if I often use 'cout' and 'cin', I write: using std::cout; using std::cin; in cpp file (never in header file as it propagates with #include). I think that noone sane will ever name a stream cout or cin. ;)

Answer 13

One shouldn't use using directive at global scope, especially in headers. However there are situations where it is appropriate even in a header file:

template <typename FloatType> inline
FloatType compute_something(FloatType x)
{
    using namespace std; //no problem since scope is limited
    return exp(x) * (sin(x) - cos(x * 2) + sin(x * 3) - cos(x * 4));
}

This is better than explicit qualification (std::sin, std::cos...) because it is shorter and has the ability to work with user defined floating point types (via Argument Dependent Lookup).

Answer 14

I recently ran into a complaint about VS 2010. It turned out that pretty much all the source files had these two lines:

using namespace std;
using namespace boost;

A lot of Boost features are going into the C++0x standard, and VS2010 has a lot of C++0x features, so suddenly these programs were not compiling.

Therefore, avoiding using namespace X; is a form of future-proofing, a way of making sure a change to the libraries and/or header files in use is not going to break a program.