namespaces

I was going to add to this , but decided against hijacking his thread And yes, I read the link that someone posted -- good info but doesn't clarify my question.

Originally Posted by valis

using a namespace globally isn't good practice anyway

I've read several programmers say that, but nobody has ever given a good explaination why it is bad. Well, so it gives the program unlimited assess to the namespace. So what? That's exactly what I want anyway. When I include header files I expect to be able to use the objects defined therein. And I've not yet seen a compiler run out of memory because I used the "using namespace std;" globally. And it doesn't significantly (if at all) increase compile time. Nor does it may the final executable program size any bigger, unless the compiler has a really crappy linker!

There are only two really good reasons I can think of for NOT using "using namespace <namespace>"

1. clarity. using the <namespace>::<object> syntax always makes it perectly clear and obvious where <object> is defined, or which namespace it is defined in.

2. when an object with the same name is declared in two or more namespaces. compiler would probably generate ambigious declaration errors without using <namespace>::<object> syntax.

Can anyone else list any other good reasons -- "its not good programming practice" is a really lousy copout.

Why use namespaces at all if you are going to use the using declaration at a filescope level?

Originally Posted by Ancient Dragon

2. when an object with the same name is declared in two or more namespaces. compiler would probably generate ambigious declaration errors without using <namespace>::<object> syntax.

This is the only reason to use namespaces and its intended purpose, is to avoid name clashes.

To really appreciate it think of times before namespaces exist. Now suppose you create a really useful library of functions and distribute them over the net. now lets suppose, you use a variable or function named count. Suddenly everyone that tries to use your library with STL will get an error because count is a stl function defined in <algorithms>

Now let's jump to today. You create the same library using a count function/variable. So now you will have 2 groups of users, the ones that use #using namespace std and those that use namespaces correctly. The second group will be able to use your library just fine. The first will be in the same boat as the pre-namespace people.

The only reason that the using namespace directive was include was to provide backwards compatibility for legacy code.

Why use namespaces at all if you are going to use the using declaration at a filescope level?

Because c++ is not c. Or maybe you mean local to a function. In either event, few functions/class can stand alone to make an entire application. You eventually have to "combine" them and then you will have name clashes if you are careless with your namespace

I enjoyed this thread on the subject a while back:

including namespaces

Originally Posted by jlou

I enjoyed this thread on the subject a while back:

including namespaces

Excellent thread! Too bad its not a sticky somewhere.

I've read several programmers say that, but nobody has ever given a good explaination why it is bad.

In a .cpp file where you're using most of the types in the other namespace by all means use using namespace. It saves some time. But in a .h file, you could end up importing all the names with other files including the .h file. You'll have more of a chance of getting into naming conflict, but conflicts resolve easily by fully qualifying the name with the namespace. (Conflicts with macros are tougher to resolve because they cause the the compiler to give strange error messages)

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.