Do not do "using namespace std", type the namespace scope....

Well it is to make sure that there are no conflicts with other C/C++ function that use the same names that exist in that namespace, that's about it I think.

Quote:

"Do not do "using namespace std;", type the namespace scope (ex.: std::cout)"

... in your header files. Because otherwise, the global namespace of any translation unit that includes that header gets polluted with the contents of the std namespace - whether you want it or not.

The whole point of having namespaces is to avoid name clashes. If I have my own vector class, which I am using in my source file along with std::vector, I don't want any random header file I include to do a using namespace std; and cause my code to fail to compile.

If I want to bring the std namespace into the global namespace, I'll do it at the proper scope - whether file, class or even individual function scope (you should really put it at the smallest useful scope).

I especially don't want the decision to be taken for me in some obscure header file I indirectly include. At least, having it in your .cpp file (at file scope) gives you some amount of control - though given how it is necessary to use fully-qualified names in header files, I've gotten into the habit of using them in all my code, for consistency reason (and it's pretty much a second nature now).

Using unqualified function names (such as for_each instead of ::std::for_each) has additional implications as to how symbols are looked up (Koenig lookup).

Also, what you read may have been referring to header files only. From what I understand, 'using' in headers is bad practice because it 'pollutes' all files that inlude the header with the same namespace. That is, if you put 'using namespace std' in your header file, and someone else includes your header, they are also now 'using' namespace std, which they may or may not want. This problem of course doesn't apply to the .cpp file, so it's probably safe to use 'using' there.

This is just what I think I've read, though, so I'm not positive about it.

See Guru of the Week No. 53:


Migrating to Namespaces
Difficulty: 4 / 10

Standard C++ includes support for namespaces and name visibility control with using declarations and directives. What's the best way to use these powerful facilities, and what's the most effective way to initially migrate your existing C++ code to a namespace-aware compiler and library?

so basically is not to "confuse the compiler"........but it has no advantage on performance.....

Namespace use has no effect whatsoever on runtime program performance; symbolic names and namespaces are all eliminated at that point. However, runtime performance is often the least important aspect—as we all know. [grin]

Here's a little real-world example of why not to put 'using namespace' in your headers. Inspired by this thread, I went to one of my .cpp files, defined a class called 'vector', and tried to create an instance of it. No go: 'ambigous access to vector, std::vector', says the compiler. But I hadn't put 'using namespace std' in that file, so there shouldn't be a conflict, right?

After a little searching, I found the culprit. In an old header file I had put 'using namespace std', back before I knew any better. So every file that included that file, and every file that included any file that included that file, and so on and so on, was 'using namespace std' whether they wanted to or not. So no 'vector' class for me (unless I were to put it in another namespace).

Anyway, that's why you shouldn't put 'using' in your header files.

Quote:

Original post by jyk Here's a little real-world example of why not to put 'using namespace' in your headers.

Sometimes you have to be careful with 'using namespace' even in cpp files. For example, I have a Pointer template class in my engine code. VC6 (in a remote procedure call header) has something defined as Pointer.

Works: include VC6 headers; include WM3 headers; 'using namespace Wm3'

Does not work: include WM3 headers; 'using namespace Wm3'; include VC6 headers

In the latter case, the compiler is confused about which Pointer to use.

I use various apis and in the past I opened up the namespace in the source file but lately have been closing them up again to prevent name clashes. I always ask "where did this function/type came from" and having namespace attached to the thing helps me a lot in this respect. I have already problems differentiating my public methods from those of mfc classes. I need to know this to see if I need to look into my docs or mfc docs. I prepend protected/private methods with "z_" to push them down the list in the class viewer which helps to see public interface easier. I think the IDE should do these kind of things and instead I have to invent things to do it.