#include and namespaces

[Luca Cerone]

Dear all,
I've a header mylib.h
that contains the line

using namespace std ; // before the declaration of my namespace
//and functions.

I put this because I'm declaring several functions that use vectors
and strings and I'd like not to write std:: in front of every of such types.

Everything works fine, but there is a small issue:
when I include the header in my main.cpp
it is like if I've written
using namespace std ;
in the preamble.

For the std it is no big deal, but for my custom namespaces it is.

So how can I use the namespace in mylib.h and its implementation mylib.cpp,
but not in the main.cpp? (unless explicitely declared of course).

Thanks a lot in advance,
Cheers, Luca

 

[Victor Bazarov]

I've a header mylib.h
that contains the line

using namespace std ; // before the declaration of my namespace
//and functions.

That's A BAD IDEA(tm).

Do not put 'using' directives in headers.

I put this because I'm declaring several functions that use vectors
and strings and I'd like not to write std:: in front of every of such types.

In this particular case the convenience of not having to type 'std::' is
trumped by the problems your 'using' directive creates. So, don't do that.

Everything works fine, but there is a small issue:
when I include the header in my main.cpp
it is like if I've written
using namespace std ;
in the preamble.

It's not "like if". You did write that. You included that specific

For the std it is no big deal, but for my custom namespaces it is.

So how can I use the namespace in mylib.h

You have to understand one *very important* thing here. "mylib.h" is
just text you're going to inject into other modules by means of the
preprocessor "#include" directive. You don't "use the namespace" in
'mylib.h' because you don't compile 'mylib.h' separately. If you "use"
anything in that header, you use that anything anywhere your header
happens to be #include'd.

and its implementation mylib.cpp,

Write

using namespace std;

in 'mylib.cpp' _only_.

but not in the main.cpp? (unless explicitely declared of course).

V

 

[Luca Cerone]

V
Hi Victor,
thanks.
I realized I didn't have to do that in the header,
I was just wondering if maybe there was some easy way to still be able to use
a certain namespace in the header not affecting all the other code.

Thanks for your help.

P.s. what is a top-posted reply?

 

[none]

I've a header mylib.h
that contains the line

using namespace std ; // before the declaration of my namespace
//and functions.

That's A BAD IDEA(tm).

Do not put 'using' directives in headers. [cut ...]
Write

using namespace std;

in 'mylib.cpp' _only_.

but not in the main.cpp? (unless explicitely declared of course).

Out of curiosity:

Personally, I never use "using" for "std" even in cpp file.
I will reject any code that put a "using namespace std;" directive in
a header file. However what are peoples opinion of specific using
directives in headers, e.g.: "using std::string;". Should they be
absolutely rejected as with "using namespace" or is there any
situation under which they are tolerable?

Yannick

 

[Alf P. Steinbach]

I've a header mylib.h
that contains the line

using namespace std ; // before the declaration of my namespace
//and functions.

That's A BAD IDEA(tm).

Do not put 'using' directives in headers. [cut ...]
Write

using namespace std;

in 'mylib.cpp' _only_.

but not in the main.cpp? (unless explicitely declared of course).

Out of curiosity:

Personally, I never use "using" for "std" even in cpp file.
I will reject any code that put a "using namespace std;" directive in
a header file. However what are peoples opinion of specific using
directives in headers, e.g.: "using std::string;". Should they be
absolutely rejected as with "using namespace" or is there any
situation under which they are tolerable?

It's pretty silly to make a rule against using the advantages of
namespaces, just because some folks do something *similar* that's
counter-productive.

In short, it is a good idea to rid the code of namespace qualifications
so that it becomes *easy to read*. It should ideally read like normal
English. Consider e.g. all the effort that Donald Knuth made for TeX
(which Latex is a variant of), to make the code read just like English.
You can dismiss my opinion here but if you dismiss the years Donald
Knuth used on code readability then you're disqualifying yourself. So
let's just agree that readable code is highly desirable, a main goal.

But while it is therefore a good idea to rid the code of namespace
qualifications, it is decidedly not a good idea to add a host of
potential *name collisions*, for example by adding the name `distance`
to the global namespace (conflicts with `std::distance), or for example
by adding `using namespace std` to the global namespace. One reasonable
approach is to simply not do that. One downright stupid, not to say
idiotic, approach is to free-associate and, due to such troubles, ban
use of the name `distance` as well as `using namespace std;` in headers.


Cheers & hth.,

- Alf

 

[none]

frob.hpp

I mean:

frob.hpp
----------
using std::string;
using std::vector;

frob.cpp
--------

and:

#include "frob.hpp"

std::vector<std::string> tokenize(const std::string& in)
{

deleted:
//> using std::string;
//> using std::vector;

vector<string> tokens;
while(something) {
string tmp1 = foo(in);
string tmp2 = bar(in);
vector<string> parts;
tokens.push_back(etc....);
// more code
// ....
}

return tokens;
}

I can't see why that should be even slighty intolerable...

I mean using std::string; in the header, not in the cpp.
It is generally accepted that "using namespace xxx;" in headers is
unacceptable. I was asking for the general opinion on "using
std::string;" in headers.


Yannick

 

[Anand Hariharan]

Dear all,
I've a header mylib.h
that contains the line

using namespace std ; // before the declaration of my namespace
//and functions.

I put this because I'm declaring several functions that use vectors
and strings and I'd like not to write std:: in front of every of such types.

Everything works fine, but there is a small issue:

As others have said, it is a bad idea. What is a small issue now,
will become a bigger issue as your program grows as well as when the
library grows with more names introduced into the std namespace.

If you use only vector or string, you could do --

using std::string;
using std::vector;

While the name 'string' being introduced into all your C++ source
files should not cause a problem, introducing the name 'vector' could.

The simplest solution is to do a search-replace of string or vector
with std::string or std::vector in your header file and you should be
able to resolve your problem.

 

[Victor Bazarov]

This is a top-posted reply.

You're welcome.

Hi Victor,
thanks.
I realized I didn't have to do that in the header,
I was just wondering if maybe there was some easy way to still be able to use
a certain namespace in the header not affecting all the other code.

Thanks for your help.

P.s. what is a top-posted reply?

 

[Victor Bazarov]

As others have said, it is a bad idea. What is a small issue now,
will become a bigger issue as your program grows as well as when the
library grows with more names introduced into the std namespace.

If you use only vector or string, you could do --

using std::string;
using std::vector;

While the name 'string' being introduced into all your C++ source
files should not cause a problem, introducing the name 'vector' could.

The simplest solution is to do a search-replace of string or vector
with std::string or std::vector in your header file and you should be
able to resolve your problem.

For toy projects I consider it totally acceptable to even do

typedef std::vector<int> vecint;
typedef std::vector<double> vecdbl;
typedef std::string str;

_in a header_ and use 'vecint', 'vecdbl' and 'str' afterwards. However,
it all hinges on the definition of "a toy project".

V

 

[Alf P. Steinbach]

For toy projects I consider it totally acceptable to even do

typedef std::vector<int> vecint;
typedef std::vector<double> vecdbl;
typedef std::string str;

_in a header_ and use 'vecint', 'vecdbl' and 'str' afterwards. However,
it all hinges on the definition of "a toy project".

More importantly, the thing that matters is whether it is in the global
namespace.

To do things properly, just do

#pragma once
namespace realProject {
using std::vector;

// Blah blah

} // namespace realProject

I would be wary of "using namespace std;" even in a custom namespace,
because anyone "using yourCustomNamespace;" could then get in trouble.
But the ability to resolve any collisions is also part of the advantages
of namespaces. So I think a ban is counter-productive, and in general,
any mechnical rule meant to replace the application of intelligence and
common sense, is in my view worse than what it cures.

Cheers,

- Alf (perhaps dissenting, somewhat)

 

[Miles Bader]

I would be wary of "using namespace std;" even in a custom namespace,
because anyone "using yourCustomNamespace;" could then get in
trouble.

Couldn't C++ anonymous namespaces solve this?

e.g.

#include <string>

namespace {
using namespace std;

namespace my_wacky_namespace {
string my_crazy_fun ();
}
}

using namespace my_wacky_namespace;

int string = 3;

std::string test ()
{
return my_crazy_fun ();
}

.... compiles fine.

[I'm not entirely sure I really understand how anonymous namespaces
work, but they seem to do the right thing here ...]

-Miles

 

[none]

On 3/1/2012 3:34 AM, Luca Cerone wrote:
I've a header mylib.h
that contains the line

using namespace std ; // before the declaration of my namespace
//and functions.

That's A BAD IDEA(tm).

Do not put 'using' directives in headers. [cut ...]
Write

using namespace std;

in 'mylib.cpp' _only_.

but not in the main.cpp? (unless explicitely declared of course).

Out of curiosity:

Personally, I never use "using" for "std" even in cpp file.
I will reject any code that put a "using namespace std;" directive in
a header file. However what are peoples opinion of specific using
directives in headers, e.g.: "using std::string;". Should they be
absolutely rejected as with "using namespace" or is there any
situation under which they are tolerable?

It's pretty silly to make a rule against using the advantages of
namespaces, just because some folks do something *similar* that's
counter-productive.

In short, it is a good idea to rid the code of namespace qualifications
so that it becomes *easy to read*. It should ideally read like normal
English. Consider e.g. all the effort that Donald Knuth made for TeX
(which Latex is a variant of), to make the code read just like English.
You can dismiss my opinion here but if you dismiss the years Donald
Knuth used on code readability then you're disqualifying yourself. So
let's just agree that readable code is highly desirable, a main goal.

But while it is therefore a good idea to rid the code of namespace
qualifications, it is decidedly not a good idea to add a host of
potential *name collisions*, for example by adding the name `distance`
to the global namespace (conflicts with `std::distance), or for example
by adding `using namespace std` to the global namespace. One reasonable
approach is to simply not do that. One downright stupid, not to say
idiotic, approach is to free-associate and, due to such troubles, ban
use of the name `distance` as well as `using namespace std;` in headers.

The point is that when a header file contains "using namespace std;",
then any cpp file that #include it directly or indirectly could
inadvertently be broken by suddently finding the there's a 'distance'
in the global namespace.

One may find that code is more readable when writing string and
distance rather than std::string and std::distance but this has to be
a local decision that is kept inside one file. If you put using
namespace std; in a header file, you may have code that for some
reader is more readable but at the same time, you risk producing
broken programs because of accidentally resolving the wrong
'distance'. A broken program trumps arguably more readable code.
In fact, it arguably make the code less readable by potentially
silently changing the meaning of identifiers.

OTOH, if a header file only contains "using std::string" or "using
std::distance;", then the effect is not as bas.

 

[Luca Cerone]

??? (..do you mean replies made not to your post but to the main thread?..)
Thanks in any case

 

[Alf P. Steinbach]

I've a header mylib.h
that contains the line

using namespace std ; // before the declaration of my namespace
//and functions.

That's A BAD IDEA(tm).

Do not put 'using' directives in headers.
[cut ...]
Write

using namespace std;

in 'mylib.cpp' _only_.

but not in the main.cpp? (unless explicitely declared of course).

Out of curiosity:

Personally, I never use "using" for "std" even in cpp file.
I will reject any code that put a "using namespace std;" directive in
a header file. However what are peoples opinion of specific using
directives in headers, e.g.: "using std::string;". Should they be
absolutely rejected as with "using namespace" or is there any
situation under which they are tolerable?

It's pretty silly to make a rule against using the advantages of
namespaces, just because some folks do something *similar* that's
counter-productive.

In short, it is a good idea to rid the code of namespace qualifications
so that it becomes *easy to read*. It should ideally read like normal
English. Consider e.g. all the effort that Donald Knuth made for TeX
(which Latex is a variant of), to make the code read just like English.
You can dismiss my opinion here but if you dismiss the years Donald
Knuth used on code readability then you're disqualifying yourself. So
let's just agree that readable code is highly desirable, a main goal.

But while it is therefore a good idea to rid the code of namespace
qualifications, it is decidedly not a good idea to add a host of
potential *name collisions*, for example by adding the name `distance`
to the global namespace (conflicts with `std::distance), or for example
by adding `using namespace std` to the global namespace. One reasonable
approach is to simply not do that. One downright stupid, not to say
idiotic, approach is to free-associate and, due to such troubles, ban
use of the name `distance` as well as `using namespace std;` in headers.

The point is that when a header file contains "using namespace std;",
then any cpp file that #include it directly or indirectly could
inadvertently be broken by suddently finding the there's a 'distance'
in the global namespace.

The leap from premise to conclusion above, is a long one.

It's not that the conclusion, involving the phrase 'could', is
necessarily wrong.

It's that the conclusion involves a rather long leap and a lot that's
unsaid, additional premises, so that that conclusion is much more likely
a product of free association and wishful thinking than a result of
clear analytical thought and understanding of the subject matter.

Since I have already said all that needs saying about the C++ side of
things here, and since the long leap (akin to the leap in "the laws of
physics are the same in all inertial systems, therefore ... (long leap)
E = mc^2") does not seem to be intentional or even understood as such,

I encourage you to *read* what you quoted, perhaps two or three times,
and *think* about e.g. necessary versus sufficient conditions for the
effect mentioned in your conclusion. Think about how "header file"
relates, or not, to "global namespace" (those two concepts seem to be
conflated in your conclusion). Possibly other articles in this thread
might also help.


Cheers & hth.,

- Alf

 

[Daniel]

More importantly, the thing that matters is whether it is in the global
namespace.

To do things properly, just do

   #pragma once
   namespace realProject {
       using std::vector;

       // Blah blah

   }  // namespace realProject

... any mechnical rule meant to replace the application of intelligence and
common sense, is in my view worse than what it cures.

What would you do about something like boost::gregorian::date? I'm
hesitant to have "date" inside even a custom namespace. From Google, I
notice a lot of projects seem to be doing

typedef boost::gregorian::date date_type

or

typedef boost::gregorian::date Date

Daniel

 

[Miles Bader]

What would you do about something like boost::gregorian::date? I'm
hesitant to have "date" inside even a custom namespace.

Why? Isn't the entire _point_ of namespaces to make such things
reasonable?

-miles

 

[Daniel]

Why?  Isn't the entire _point_ of namespaces to make such things
reasonable?

What if the class was some_namespace::i? boost::gregorian::date is a
little different from that, but not that much different. It doesn't
help that the standard library and boost both follow naming
conventions for class names that are not common in other code. Hence,
perhaps, the greater number of hits accorded "typedef
boost::gregorian::date Date" etc. versus "using
boost::gregorian::date".

Daniel

 

[Juha Nieminen]

I'd like not to write std:: in front of every of such types.

Why?

 

[Miles Bader]

What if the class was some_namespace::i?

Then ... nothing? some_namespace::i seems fine to me (it might be
annoying for the _implementors_ of various stuff in some_namespace,
but hey, it's their choice)...

It doesn't help that the standard library and boost both follow
naming conventions for class names that are not common in other
code. Hence, perhaps, the greater number of hits accorded "typedef
boost::gregorian::date Date" etc. versus "using
boost::gregorian::date".

Meh; "A foolish consistency is the hobgoblin of little minds"

-miles

 

[Alf P. Steinbach]

What if the class was some_namespace::i?

namespace sni = some_namespace::i;

sni::foobar();

boost::gregorian::date is a
little different from that, but not that much different. It doesn't
help that the standard library and boost both follow naming
conventions for class names that are not common in other code. Hence,
perhaps, the greater number of hits accorded "typedef
boost::gregorian::date Date" etc. versus "using
boost::gregorian::date".

Yah.


Cheers,

- Alf