std:: or namespace std

This is a discussion on std:: or namespace std within the C++ Programming forums, part of the General Programming Boards category; I see some people who use std:: .Isn't it better to use namespace std so we don't have to write ...

Employing "using namespace std;" everywhere does a bit more than (effectively) putting std:: in front of symbol names that are within std. It formally tells the compiler to look within namespace std for candidate names, when trying to resolve a particular name. It can also introduce ambiguity in some circumstances, particularly if multiple namespaces and multiple using directives are employed. (Ambiguity refers to code that has multiple possible meanings, which the compiler cannot resolve, so the compiler must reject the code) -- in which case it is still necessary to use the namespace prefix even though the using directive is in effect. This is one reason for a common guideline that "using namespace" directives should not be employed in header files; once a "using namespace" directive is employed, its effects cannot be turned off within that translation unit (aka source file).

The main disadvantage of using the std:: prefix is additional typing.

Personally, I almost never employ "using namespace" directives, as I consider the additional typing a small price to pay for code without ambiguity.

It's better to use std:: because 'using namespace std' puts everything inside the namespace std in the global namespace; thus, ruining the whole point of namespaces. When you use std:: , you do not mess with the global namespace, which is what you want to do.

It depends...
If that's the only namespace you're using, then sure go ahead.
If you're writing a large program with multiple namespaces, where conflicts could occur, then it's safer to be explicit.
For example, if a .cpp file is using code from the std:: namespace and the blah:: namespace, and both have a class named vector<T> (I know, it's pretty stupid for the makers of blah to use such a standard name, but what can you do). Now if you try to create a vector<int>, the compiler won't know which namespace you're talking about.
There's also even more evil situations where the compiler might mix & match classes from different namespaces without any errors, but then leads to a bug in your program.

In any case, you should NEVER write a using statement in a header file since it will propagate to every file that includes that header. So you should ALWAYS explicitly qualify all namespaces in header files.

Don't forget the global namespace. Putting the std namespace in the global namespace could create conflicts. You might want to know that a vector is not only an STL container but also a math entity thus it's very possible that someone calls a class vector. Putting the std namespace in the global namespace would cause a conflict between std::vector and ::vector.

Don't forget the global namespace. Putting the std namespace in the global namespace could create conflicts. You might want to know that a vector is not only an STL container but also a math entity thus it's very possible that someone calls a class vector. Putting the std namespace in the global namespace would cause a conflict between std::vector and ::vector.

But "using namespace" doesn't cause a problem with that. It doesn't change the namespace membership of anything, it just changes the rules used when looking up symbols. Even with "using namespace std;" you can still distinguish between std::vector and ::vector. It is only the name reference "vector" which is ambiguous.

Don't forget the global namespace. Putting the std namespace in the global namespace could create conflicts. You might want to know that a vector is not only an STL container but also a math entity thus it's very possible that someone calls a class vector. Putting the std namespace in the global namespace would cause a conflict between std::vector and ::vector.

That's not true: "using namespace std;" does not put anything into the global (unnamed) namespace. Instead, it tells the compiler that, when trying to resolve a name to something (an object, a type, a function, etc) that it is required to look in namespace std for matching candidates.

If (1) there was something named ::cout in scope, (2) <iostream> had been #include'd, and (3) a "using namespace std;" was in effect, then the line;

Code:

cout << "Hello\n";

within a function would be ambiguous, because the compiler would find that both ::cout and std::cout are both viable candidates for matching the name "cout". That ambiguity would be resolved by (unambiguously) qualifying the name with the namespace of the cout that was intended to be used by the programmer.

Note that if there is ambiguity in names because you are using a using directive, it will not necessarily be flagged as an error by the compiler. The compiler might just make the wrong choice and you won't know about it until your application works incorrectly or crashes (if you're lucky). Admittedly this will be rare, but I've seen a handful of problems on C++ forums that were the result of a using directive causing a name to be ambiguous. For contrived examples see this thread:

Note that if there is ambiguity in names because you are using a using directive, it will not necessarily be flagged as an error by the compiler. The compiler might just make the wrong choice and you won't know about it until your application works incorrectly or crashes (if you're lucky). Admittedly this will be rare, but I've seen a handful of problems on C++ forums that were the result of a using directive causing a name to be ambiguous. For contrived examples see this thread:

The example in that thread is a practical problem, but has got nothing to do with ambiguity resulting from functions in multiple namespaces. It is a problem of function overloading, with the compiler being required (unambiguously) to call a particular function, but the programmer incorrectly expecting something else to be invoked (the count algorithm in the <algorithm> header, which is not #include'd so the compiler will never consider it as a candidate to be called in any circumstance). The undefined behaviour occurs because the count() function happens to fall off the end of an array because of the arguments it is passed.

I guess the point of the examples (there are several in the thread) are that it is possible for using directives or declarations to have adverse effects that do not necessarily cause compiler errors. Notice the last example fails even if all proper headers are included.

Any function in the STL.
vector, map, string, cout, cin, etc.
IF you find the compiler complaining about not finding a function and you've included a header, try putting std:: before. Also use some common sense, of course