Why std:: and not using namespace std?

Why use std:: instead of using namespace std? I was recently told that I should use std:: in my header files as opposed to using namespace std but I don't really know why. Should I be using std:: in .cpp files as well? When is it acceptable to use using namespace std? I just seems like alot of extra typing.

You use the resolution scope operator wherever you use a member of namespace std. Yes it is a lot of extra typing, but it makes sure that you want to use that particular member of std rather than a user defined member of something else. Say you want to declare a string variable from the std namespace:

Code:

---

std::string sSomeVar;

---

But you create your own string class, and want to declare an object of that string:

Code:

---

class string
{
    /*Class members here*/
};

string sMyStringObject;

---

If you use the namespace std, and want to declare an object of your class, the compiler will get confused and most likely spit out an error:

Code:

---

using namespace std;

string sSomeVar; /*String from std namespace*/
string sMyStringObject; /*Object of class*/

/*Compiler doesn't know what string class to pick!*/

---

Conclusion: safer to use the scope resolution operator ::

> When is it acceptable to use using namespace std?
As a hack to get old code up and running.

> I was recently told that I should use std:: in my header files as opposed to using namespace std but I don't really know why.
Because if someone else uses your header, then they get the whole namespace whether they like it or not.
And there's no way to undo the damage, so they have to come to you to edit the code.

> Should I be using std:: in .cpp files as well?
There you have more choice. But you might consider say
using std::cout;
if you happen to be using cout a lot, and use the std:: prefix for everything else.

If you're working on your own, there isn't a lot in it.
But if you end up working in large teams, with many namespaces flying about, then knowing how to be strict about such things is a big help.

Quote:

---

Originally Posted by swappo

I was recently told that I should use std:: in my header files as opposed to using namespace std but I don't really know why.

---

You should avoid namespace level using directives (e.g., using namespace std) and using declarations in header files (e.g., using std::cout). The reasons have been outlined by legit and Salem. However, note that this is not necessarily the case for a more restricted scope, e.g., the use of the using declaration to bring in names from a base class that would otherwise be hidden, or in the definition of an inline function.

Quote:

---

Originally Posted by legit

If you use the namespace std, and want to declare an object of your class, the compiler will get confused and most likely spit out an error:

---

Quote:

---

Originally Posted by Salem

And there's no way to undo the damage, so they have to come to you to edit the code.

---

Note that you can still fully qualify the names even when using directives and using declarations are in effect... but if you do not do this when you should, it could be possible for your code to compile and be mysteriously incorrect.

"using namespace std;" can introduce ambiguity in any code that employs named objects or functions from multiple namespaces. The result of that ambiguity is code that cannot compile, or code that compiles and gives the wrong results, and the effects cannot be undone. The only fix is to prefix the affected names with the namespace name (i.e. to use use "std::<name>" or "conflicting_namespace::<name>" syntax) or to modify the code to eliminate "using namespace" directives.

The second option is impossible for commercial libraries distributed without source (i.e. in the form of header files and compiled libraries). Legally and contractually, "using namespace std;" in a header file can render a commercial library unfit for its stated purpose.

The sad thing is that quite a few text books employ "using namespace std;" in all their examples, with a strong implication that is good practice. It is anything but.