Which way is better ?

This is a discussion on Which way is better ? within the C++ Programming forums, part of the General Programming Boards category; I was just wondering is
Code:
using namespace std;
A good idea or just program without it?...

Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

It is generally bad form to put the std using directive in header files or above other header #includes. So except for simple programs I'd stay away from doing that.

Indeed & completely agreed - using directives (std or otherwise) should never[1] be found in header-files, because it "messes" with what happens in code that includes that header file beyond what you can expect.

[1] I would consider exceptions to this that you may for example implement some sort of replacement functions for some standard functions, and thus do something like:

Code:

// mydebug.h
using MyDebug::somefunc;
...

So if you include "mydebug.h" you get some debugging version of the standard function, otherwise you get the normal version. But that is a very special case.

I would encourage you to use 'using' directives.
I would even encourage you to use 'using namespace' directives.
I'll even tell you that you will eventually have to use a 'using' directive.

The problems come from putting such a directive in a header or at the top of source files from global scope. It is evil. If you have ambiguities, collisions, you must fully qualify the name. Any 'using' directive can cause these ambiguities. If you must fully qualify the name there is no point to namespaces. If it comes to that, you may as well just be using the C style 'long_name_prefix'.

I've always used the 'local' or '<anonymous>::local' "trick" to get just what I need to implement the source for a particular translation unit.

[Edit]

using directives (std or otherwise) should never[1] be found in header-files

This is silly. Or maybe you just don't mean what you said. If the directive is enclosed in some private scope it shouldn't cause any problems.

If you are dealing with templates and you need a function symbol to resolve to non-standard overloads you have no choice.
[/Edit]

I would encourage you to use 'using' directives.
I would even encourage you to use 'using namespace' directives.
I'll even tell you that you will eventually have to use a 'using' directive.

The problems come from putting such a directive in a header or at the top of source files from global scope. It is evil. If you have ambiguities, collisions, you must fully qualify the name. Any 'using' directive can cause these ambiguities. If you must fully qualify the name there is no point to namespaces. If it comes to that, you may as well just be using the C style 'long_name_prefix'.

I am typically against using directives, since I like to use them as categories. If I put functions inside a namespace String, I won't have to prefix those functions "Str" or such.
So I have this:

Code:

namespace String
{
std::string Cut(std::string&, std::string&);
}

And then do...

Code:

using namespace Strings;
Cut(...);

...instead of...

Code:

String::Cut(...);

Which is more readable?
It can get worse with other functions such as if you have functions named "Load" or similar.
But using isn't evil. Oh no. There is a time where it can be applied that gives more readability. I'm just saying one should be careful in doing so, and that fully expressing them isn't so bad as it sounds, and we're not back in the C era.

The thing with using namespaces as categories is that it wouldn't really avoid conflicts, would it? If your library puts math-related functions into a namespace called Math and my library does the same since that's the most logical thing to do in order to categorize things, there would still be naming conflicts?

On the other hand (top-level) namespaces like std or boost don't categorize things and just try to be library-specific...

But since I don't really care that it is YourLibrary that I'm using (because the only math library I am using is yours, whereas I might care more that it is the math module of YourLibrary) why shouldn't I do this in source files?