using namespace

[Christian Christmann]

Hi,

are there any drawbacks using

"using namespace std"

instead of defining the required namespaces like

using std::cout

separately?

The first solution is a more convenient one since you just need one
statement but can the code suffer from it?

Chris

 

[Victor Bazarov]

are there any drawbacks using

"using namespace std"

instead of defining the required namespaces like

using std::cout

separately?

The first solution is a more convenient one since you just need one
statement but can the code suffer from it?

This should be in the FAQ. I checked. It's not. But it should be.

Anyway, 'using namespace std' brings _all_ names from 'std' into the
current scope. And the policy should be to bring only the names you
are _actually_using_.

V

 

[ben]

I tend to use both -- using namespace ... to bring in the whole namespace;
using ... to resolve individual name clash, if any. So:

#include <string>

namespace my
{
class string
{
};
}

int main()
{
using namespace std; // make std::string available
using namespace my; // make my::string available
using std::string; // use std::string instead of
my::string

string ben = "Hello";
}


Regards,
Ben

 

[John Carson]

Hi,

are there any drawbacks using

"using namespace std"

instead of defining the required namespaces like

using std::cout

separately?

Yes, the drawback is that you will have a name clash if you use any name
that is also used in the standard namespace (from among the header files you
#include).

using namespace std;

effectively tosses out the protection that the std namespace offers against
name clashes by putting all of its names in the global namespace. If every
other name is namespace-qualified, then this won't matter, but having
everything else namespace-qualified will mean a lot of typing.

On the other hand, you don't always need the protection that namespaces
offers. The fewer identifiers you are working with, the lower the risk of a
clash.

 

[Kristo]

This should be in the FAQ. I checked. It's not. But it should be.

Anyway, 'using namespace std' brings _all_ names from 'std' into the
current scope. And the policy should be to bring only the names you
are _actually_using_.

I emailed Bjarne Stroustrup about this a long time ago. It wasn't in
his FAQ either. He seemed ok with "using namespace std;". He said
that the classes in the standard library are common enough that when
you see (for example) "string" you know it means "std::string". For
that reason, I think the policy on "using namespace std;" should be up
to your group's coding standard, not an absolute. *HOWEVER*, it has
been stressed on this ng many times that such a directive has no place
in a header file because it brings the entire std namespace into any
file that #includes it. IMHO this is very good advice.

I agree, this should be in the FAQ.

Kristo

 

[Ioannis Vranos]

Hi,

are there any drawbacks using

"using namespace std"

instead of defining the required namespaces like

using std::cout

separately?

The first solution is a more convenient one since you just need one
statement but can the code suffer from it?

When you deal with a couple of std facilities, then use "using std::" statements. If you
deal with more than two, use "using namespace std;" statements.

Define your applications inside a new namespace of theirs.

 

[Ioannis Vranos]

I tend to use both -- using namespace ... to bring in the whole namespace;
using ... to resolve individual name clash, if any. So:

#include <string>

namespace my
{
class string
{
};
}

int main()
{
using namespace std; // make std::string available
using namespace my; // make my::string available
using std::string; // use std::string instead of
my::string

string ben = "Hello";
}

This is the only nice one I have seen today! (and mentioned this way explicitly in another
message in this thread and some other thread).

 

[Ioannis Vranos]

Yes, the drawback is that you will have a name clash if you use any name
that is also used in the standard namespace (from among the header files
you #include).

using namespace std;

effectively tosses out the protection that the std namespace offers
against name clashes by putting all of its names in the global
namespace. If every other name is namespace-qualified, then this won't
matter, but having everything else namespace-qualified will mean a lot
of typing.

On the other hand, you don't always need the protection that namespaces
offers. The fewer identifiers you are working with, the lower the risk
of a clash.

"using std::" statements in the global namespace, also pollute it. As I said in another
thread on a similar subject, we should place our facilities (both declarations and
definitions) inside a new namespace of the application or library:



namespace FileManagerApp
{
using std::cout;
using std::endl;

class Someclass
{
// ...
};

// ...
}


or


namespace FileManagerApp
{
using namespace std;


class Someclass
{
// ...
};

// ...
}"

 

[John Carson]

"using std::" statements in the global namespace, also pollute it.

Of course (though "pollute" is overly negative). Just not by as much.

As I said in another thread on a similar subject, we should place our
facilities (both declarations and definitions) inside a new namespace
of the application or library:

namespace FileManagerApp
{
using std::cout;
using std::endl;

class Someclass
{
// ...
};

// ...
}


or


namespace FileManagerApp
{
using namespace std;


class Someclass
{
// ...
};

// ...
}"

No argument from me that this is the best way to avoid name clashes. I use
the technique myself some of the time. However, I don't believe that name
clashes are always such a risk that this technique is obligatory. Your
second version has significantly more risk of name clashes than your first,
so apparently you are prepared to countenance increased risk sometimes in
order to save typing. By the way, I am taking it for granted that any
directive/declaration that puts something into the global namespace is in a
..cpp file, not a header file.

 

[Ioannis Vranos]

No argument from me that this is the best way to avoid name clashes. I
use the technique myself some of the time. However, I don't believe that
name clashes are always such a risk that this technique is obligatory.

It is always nice to define an application inside a new application namespace. Also this
makes the application a bit more modular, and perhaps use it as a library itself (being
windows specific, e.g. compile it as a dll).

Your second version has significantly more risk of name clashes than
your first, so apparently you are prepared to countenance increased risk
sometimes in order to save typing.

Well the above were mainly about .cpp files. In a more complete example:


FileManagerApp.h:

#include <string>

namespace FileManagerApp
{
class SomeClass
{
// ...

public:

std::string SomeMethod() const;

// ...
};

// ...
}




FileManager.cpp:


#include <string>
#include "FileManagerApp.h"

namespace FileManagerApp
{
// Could use this way too:
// using namespace std;

class SomeClass
{
// ...

public:

std::string SomeClass::SomeMethod() const
{
using namespace std;

// ...
}


// ...
};

// ...
}

By the way, I am taking it for
granted that any directive/declaration that puts something into the
global namespace is in a .cpp file, not a header file.

Yes, but better place nothing from std in the *global* namespace.

 

[Bob Hairgrove]

I emailed Bjarne Stroustrup about this a long time ago. It wasn't in
his FAQ either. He seemed ok with "using namespace std;". He said
that the classes in the standard library are common enough that when
you see (for example) "string" you know it means "std::string". For
that reason, I think the policy on "using namespace std;" should be up
to your group's coding standard, not an absolute. *HOWEVER*, it has
been stressed on this ng many times that such a directive has no place
in a header file because it brings the entire std namespace into any
file that #includes it. IMHO this is very good advice.

I agree, this should be in the FAQ.

Kristo

With all due respect to Mr. Stroustrup, I believe this has two
distinct drawbacks:

(a) Once an implementation file has "using namespace std;" ANYWHERE
(including inside a function's definition body), it assumes that there
will never be any new names added to the standard library, or that the
code in question will never have to be recompiled at a later date when
there might very well be newer names in there;

(b) It also assumes that all names currently (i.e. at the point in
time when the code was written) defined by the standard library in
namespace std are known.

Of course, we all know that there is a std::string. But do all of you
honestly believe that you know EVERY name in namespace std? And if
not, there is always the chance that you might try to define it for
your own code. Or someone else might do it later when you aren't
around anymore.

And what about junior programmers?