Using a namespace "globally" causes an ambiguity problem (which often means your program cannot compile) if you have more than one namespace, with things of the same name in different namespaces.
Consider this example;
Code:
#include <iostream>
int main()
{
cout << "Hello\n"; // compiler will not be able to work out which cout you intend
}
The problem with using namespace directives is that, once done, there is no way to undo their effect. So, if we expand on the previous example, and do this;
Code:
// header1.h
#include <iostream>
class Foo
{
public:
void Print(ostream &x);
}
and
Code:
// header2.h
namespace X
{
int cout;
}
using namespace X;
and then try to bring them together
Code:
#include "header1.h"
#include "header2.h"
int main()
{
cout << "Hello"; // always ambiguous because of the two header files above
}
In practice, as a program grows, one bit of functionality is often implemented first and, later, another header file is brought in so new functionality can be used. If that header file makes use of a global "using namespace" it can, just by being #include'd, break code that worked perfectly before.
If the header file is (say) from a third-party library, where the programmer does not have access to source of the library [as is the case with a lot of commercial libraries, that are distributed with header files and compiled libraries only], the header file cannot be changed as it would break the library. The only alternative is to modify the working program (eg to use fully qualified names like std::cout rather than cout) which is time consuming and [in large programs] error prone. Unfortunately, the only third alternative is to throw away the library and use a different one, as it is not possible to turn off the effects of a "using namespace" directive. That third alternative is not particularly good for the supplier of the library.