Using std Namespace

Question

There seem to be different views on using \'using\' with respect to the std namespace.

Some say use \' using namespace std\', other say don\'t but rathe

Answer 1

using namespace std imports the content of the std namespace in the current one. Thus, the advantage is that you won't have to type std:: in front of all functions of that namespace. However, it may happen that you have different namespaces that have functions of the same name. Thus, you may end not calling the one you want.

Specifying manually which ones you want to import in std prevents that from happening, but may result in a long list of using at the beginning of your file, which some developer will find ugly ;) !

Personally, I prefer specifying the namespace each time I use use a function, except when the namespace is too long, in which case I put some using at the beginning of the file.

EDIT: as noted in another answer, you should never put a using namespace in a header file, as it will propagage to all files including this header and thus may produce unwanted behavior.

EDIT2: corrected my answer, thanks to Charles comment.

Answer 2

If you don't have a risk of name conflicts in your code with std and other libraries you can use :

using namespace std;

But if you want know precisely the dependancy of your code for documentation or there is a risk of name conflicts use the other way :

using std::string;
using std::cout;

The third solution, don't use these solutions and write std:: before each use in code brings you more security but, maybe a little heaviness in the code...

Answer 3

Much like in Java where you can use either can include java.util.* or simply select each class individually, it depends on style. Note that you don't want one using namespace std at the start of your file/wide scope because you will pollute the namespace and possibly have clashes, defeating the point of namespaces. But if you have a function that uses a lot of STL, it clutters the code to have a jumble of prefixing syntax in your logic and you should probably consider using either using namespace std (when using a variety of classes) or individual usings (when using a few classes often).

Answer 4

Never use using namespace at global scope in an header file. That can leads to conflict and the person in charge of the file where the conflict appears has no control on the cause.

In implementation file, the choices are far less well cut.

• Putting a using namespace std brings all the symbols from that namespaces. This can be troublesome as nearly no body know all the symbols which are there (so having a policy of no conflict is impossible to apply in practice) without speaking of the symbols which will be added. And the C++ standard allows an header to add symbols from other headers (the C one doesn't allow that). It still can work well in practice to simplify the writing in controlled case. And if an error occur, it is detected in the file which has the problem.

• Putting using std::name; has the advantage of simplicity of writing without the risk of importing unknown symbols. The cost is that you have to import explicitly all wanted symbols.

• Explicitly qualifying add a little clutter, but I think it is the less trouble some practice.

In my project, I use explicit qualification for all names, I accept using std::name, I fight against using namespace std (we have an lisp interpreter which has his own list type and so conflict is a sure thing).

For other namespaces, you have also to take into account the naming conventions used. I know of a project which use namespace (for versionning) and prefix on names. Doing a using namespace X then is nearly without risk and not doing it leads to stupid looking code PrefixNS::pfxMyFunction(...).

There are some cases where you want to import the symbols. std::swap is the most common case: you import std::swap and then use swap unqualified. Argument dependent lookup will find an adequate swap in the namespace of the type if there is one and fall back to the standard template if there is none.

---

Edit:

In the comments, Michael Burr wonders if the conflicts occur in real world. Here is a real live exemple. We have an extension language with is a lisp dialect. Our interpreter has an include file, lisp.h containing

typedef struct list {} list;

We had to integrate and adapt some code (which I'll name "engine") which looked like this:

#include <list>
...
using std::list;
...
void foo(list const&) {}

So we modified like this:

#include <list>

#include "module.h"
...
using std::list;
...
void foo(list const&) {}

Good. Everything work. Some months later, "module.h" was modified to include "list.h". The tests passed. "module" hadn't be modified in a way that affected its ABI, so "engine" library could be used without re-compiling its users. Integration tests were OK. New "module" published. Next compilation of engine broke when its code hasn't be modified.