Is using namespace std; really worth it?

[Whovian]

It's quite common among beginners to put int a using namespace std; so they wouldn't have to type the fully qualified name for anything included in headers. To prevent naming conflicts, though, some people don't use it and type in an std:: before everything in headers without the .h extension. My question was, is it worth the lack of having to type so much to get the potential naming conflicts?

[PanGalactic]

Using directives are a newbie (and old-timer) crutch. Most professional C++ developers shun using directives. Instead they use fully-qualified names or use using declarations when it makes sense. For longer namespaces, namespace aliases and using declarations are commonly used.

[Cubbi]

There are a few things to consider

1) The obvious: a namespace using in global scope of a header file or before an #include should never be used.

2) C++ source code is much easier to read with std::. When someone reads std::copy in your code, they know you're referring to the C++ standard algorithm and not boost::copy or some company::team::project::copy() function you've pulled in from some obscure header file. Granted, it doesn't really promise that: the only certain way is to write ::std::copy, but almost nobody goes that far.

3) Naming conflicts: any standard include file is permitted to include any other standard include file, and this can (and does) change version to version, in the same compiler. #include <iostream> gives you std::string on some systems. Who's to say it doesn't give you std::count or std::ref or some other simple-looking name as well?


On the other hand

1) As Sutter/Alexandrescu and some other major playes in the C++ community have argued, a namespace using is perfectly fine in implementation files (a cpp file), especially if it's function-local. There should be no emotional shunning of a language feature. If it's useful somewhere, it should be used.

[Duthomhas]

Cubbi +1

There is absolutely nothing wrong with using directives, so long as you keep them out of header files (and anything else that would contaminate other people's code).

The bigger concern is that people should be more careful to stick all their stuff in namespaces -- and very few do. Namespaces don't just save your behind when compiling, they do when linking also.

[JLBorges]

In implementation files (e.g. .cpp files), the rule is more of a stylistic rule, but is still important. Basically, using explicit namespace prefixes makes the code clearer, because it is immediately obvious what facilities are being used and where they are coming from. And more portable, because namespace clashes cannot occur between LLVM code and other namespaces. The portability rule is important because different standard library implementations expose different symbols (potentially ones they shouldn't), and future revisions to the C++ standard will add more symbols to the std namespace. As such, we never use 'using namespace std;' in LLVM.

- LLVM Coding Standards

[Duthomhas]

Good point, but that is always the danger of using namespace x;. While obnoxious, it is possible to import a specific symbol of your choosing to take precedence over any existing symbol:

#include <iostream>
#include <string>
using namespace std;

namespace foo
  {
  struct string
    {
    const char* s;
    string( const char* s ): s( s ) { }
    const char* c_str() const { return s; }
    };

  ostream& operator << ( ostream& outs, const string& s )  // not an issue here
    {
    return outs << "\"" << s.c_str() << "\"";
    }
  } // namespace foo

int main()
  {
  string hello( "Hello world!" );

  using foo::string;  // only obnoxious here
  string hola( "Hola mundo!" );

  cout << hello << endl;
  cout << hola  << endl;

  return 0;
  }

Not perfect, but not horribly crufty, either. The new C++11 standard has already stomped all over common naming symbols... users can easily get used to it and/or use a simple grep and replace over their existing code.

If you keep your stuff in your own namespaces, then the issue really isn't an issue...

[JLBorges]

> Good point, but that is always the danger of using namespace x;

The loss of clarity is always a danger with any using namespace x;

Portability is a primary issue only for namespaces like std or CORBA where many different implementations exist; and these implementations may (in practice often do)

expose different symbols (potentially ones they shouldn't)

.