should "using namespace std" be used?

[Pep]

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify that
the std namespace is being used instead of tagging each member of the
namespace?

[Jim Langston]

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

For non trivial code, using std namespace; may be okay, but I never use it
then either.

The problem with using std namespace; is that it brings everything into the
unnamed namespace. Usually this doesn't cause problems, until you try to
declare a function or variable or class with the same name as something else
in the std namespace.

If you don't really like doing std::cout std::endl etc... just bring what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

[Pep]

Jim Langston wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?
For non trivial code, using std namespace; may be okay, but I never use it
then either.

The problem with using std namespace; is that it brings everything into
the
unnamed namespace. Usually this doesn't cause problems, until you try to
declare a function or variable or class with the same name as something
else in the std namespace.

This is where I dither over the choice. Given that all c++ programmers are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std and as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.
If you don't really like doing std::cout std::endl etc... just bring what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

Yet, as a new developer on a project that has been badly documented and laid
out over several hundred source files, I might miss the fact that cout and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

[Sumit Rajan]

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

This is covered in the FAQ:
http://www.parashift.com/c++-faq-lit....html#faq-27.5

Regards,
Sumit.
--
Sumit Rajan <su*********@gmail.com>

[Pep]

Sumit Rajan wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

This is covered in the FAQ:
http://www.parashift.com/c++-faq-lit....html#faq-27.5

Regards,
Sumit.
--
Sumit Rajan <su*********@gmail.com>

Whilst I agree with the FAQ in a new project, it does not really address the
scenario I placed in my reply to Jim Langston. Yes it is possible to
decide at the begginning of a project but badly documented projects which I
have worked on do not make the distinction very clearly and when the long
time serving inmates of the project leave, they take that sort of knowledge
with them. In the past I have wasted 3 days on a simple bug simply because
it was not documented that some of the std entities had been replaced with
locally defined ones.

Then again maybe I should simply stick to contracts that involve properly
documented designs, yeah right :)

[Daniel T.]

In article <e7**********@pop-news.nl.colt.net>, Pep <pe*@nowhere.com>
wrote:

Sumit Rajan wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

This is covered in the FAQ:
http://www.parashift.com/c++-faq-lit....html#faq-27.5

Whilst I agree with the FAQ in a new project, it does not really address the
scenario I placed in my reply to Jim Langston. Yes it is possible to
decide at the begginning of a project but badly documented projects which I
have worked on do not make the distinction very clearly and when the long
time serving inmates of the project leave, they take that sort of knowledge
with them. In the past I have wasted 3 days on a simple bug simply because
it was not documented that some of the std entities had been replaced with
locally defined ones.

Then again maybe I should simply stick to contracts that involve properly
documented designs, yeah right :)

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

The supposed "problem" of "using namespace std" allowing the compiler
see all the std names isn't a problem at all, and refusing to have using
declarations and directives in your code defeats the purpose of the
namespace mechanism.

See "C++ Coding Standards" by Sutter & Alexandrescu for a more
reasonable rule regarding the "using" keyword.

[Marcus Kwok]

Daniel T. <da******@earthlink.net> wrote:

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Pep]

Marcus Kwok wrote:

Daniel T. <da******@earthlink.net> wrote:

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

Hmm, I tend to agree with this view. Adding "using namespace std" in source
files is fine as it is local to the coding point whereas adding to include
files can affect the project in ways not intended.

Then again it would be nice if just once when I join a project I find well
documented code with good design docs, just as of course I always do when
starting a new project ;)

[Marcus Kwok]

Pep <pe*@nowhere.com> wrote:

Marcus Kwok wrote:

Daniel T. <da******@earthlink.net> wrote:

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

Hmm, I tend to agree with this view. Adding "using namespace std" in source
files is fine as it is local to the coding point whereas adding to include
files can affect the project in ways not intended.

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migr...namespaces.htm

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Richard Herring]

In message <e7**********@news-int.gatech.edu>, Marcus Kwok
<ri******@gehennom.invalid> writes

Pep <pe*@nowhere.com> wrote:

Marcus Kwok wrote:

Daniel T. <da******@earthlink.net> wrote:
I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

Hmm, I tend to agree with this view. Adding "using namespace std" in source
files is fine as it is local to the coding point whereas adding to include
files can affect the project in ways not intended.

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migr...namespaces.htm

where you'll find this gem:

"I find it helpful to think of a using directive as a marauding army of
crazed barbarians that sows indiscriminate destruction wherever it
passes"

--
Richard Herring

[Howard]

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Jim Langston wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

For non trivial code, using std namespace; may be okay, but I never use
it
then either.

The problem with using std namespace; is that it brings everything into
the
unnamed namespace. Usually this doesn't cause problems, until you try to
declare a function or variable or class with the same name as something
else in the std namespace.

This is where I dither over the choice. Given that all c++ programmers
are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std and
as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.

If you don't really like doing std::cout std::endl etc... just bring what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

Yet, as a new developer on a project that has been badly documented and
laid
out over several hundred source files, I might miss the fact that cout and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

I don't find it particularly inconvient to type the extra characters for
things lke std::cout, so most of the time I just type it out.

But if I'm working with other developers, I'll often put using statements
(such as "using std::cout;") at the top of a given function. That way, the
using statements for that function are right there at the entry to the
function, where other developers can immediately see what the following code
is referring to. (Which is good self-documentation!)

-Howard

[mlimber]

Daniel T. wrote:

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

The supposed "problem" of "using namespace std" allowing the compiler
see all the std names isn't a problem at all, and refusing to have using
declarations and directives in your code defeats the purpose of the
namespace mechanism.

See "C++ Coding Standards" by Sutter & Alexandrescu for a more
reasonable rule regarding the "using" keyword.

As Daniel T. notes, there are different schools of thought on the
matter. The rule from _C++ Coding Standards_, item 59 (italics in
original) is: "You can and should use namespace using declarations and
directives liberally /in your implementation files after #include
directives/ and feel good about it. Despite repeated assertions to the
contrary, namespace using declarations and directives are not evil and
they do not defeat the purposes of namespaces. Rather, they are what
make namespaces usable."

Cheers! --M

[Cy Edmunds]

"Howard" <al*****@hotmail.com> wrote in message
news:84*******************@bgtnsc04-news.ops.worldnet.att.net...

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Jim Langston wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...
Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

For non trivial code, using std namespace; may be okay, but I never use
it
then either.

The problem with using std namespace; is that it brings everything into
the
unnamed namespace. Usually this doesn't cause problems, until you try
to
declare a function or variable or class with the same name as something
else in the std namespace.

This is where I dither over the choice. Given that all c++ programmers
are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace
tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std and
as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.

If you don't really like doing std::cout std::endl etc... just bring
what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

Yet, as a new developer on a project that has been badly documented and
laid
out over several hundred source files, I might miss the fact that cout
and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

I don't find it particularly inconvient to type the extra characters for
things lke std::cout, so most of the time I just type it out.

But if I'm working with other developers, I'll often put using statements
(such as "using std::cout;") at the top of a given function. That way,
the using statements for that function are right there at the entry to the
function, where other developers can immediately see what the following
code is referring to. (Which is good self-documentation!)

-Howard

I agree that it is good documentation, but I find it hard to maintain. If
you refactor your code in such a way that the function is no longer used you
have to remember to get rid of your using clause also. Of course it is not
an error to claim to be using something you are not, but it is misleading.

Cy

[Cy Edmunds]

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

In article <e7**********@pop-news.nl.colt.net>, Pep <pe*@nowhere.com>
wrote:

Sumit Rajan wrote:

>
> "Pep" <pe*@nowhere.com> wrote in message
> news:e7**********@pop-news.nl.colt.net...
>> Is it best to include the code "using namespace std;" in the source or
>> should each keyword in the std namespace be qualified by the namespace
>> tag,
>> such as
>>
>> std::cout << "using std namespace" << std::endl;
>>
>> Myself I am not sure which I prefer, it is certainly easier to specify
>> that
>> the std namespace is being used instead of tagging each member of the
>> namespace?
>
>
> This is covered in the FAQ:
> http://www.parashift.com/c++-faq-lit....html#faq-27.5
Whilst I agree with the FAQ in a new project, it does not really address
the
scenario I placed in my reply to Jim Langston. Yes it is possible to
decide at the begginning of a project but badly documented projects which
I
have worked on do not make the distinction very clearly and when the long
time serving inmates of the project leave, they take that sort of
knowledge
with them. In the past I have wasted 3 days on a simple bug simply
because
it was not documented that some of the std entities had been replaced
with
locally defined ones.

Then again maybe I should simply stick to contracts that involve properly
documented designs, yeah right :)

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

The supposed "problem" of "using namespace std" allowing the compiler
see all the std names isn't a problem at all,

I don't think you have thought this through. What happens when a revised
standard comes out and the standard namespace gets another large injections
of names? For that matter, what happens when you refactor your own code and
introduce a symbol which conflicts with a standard identifier?
Maintainability is too important to compromise for the sake of avoiding
typing std:: in front of a few symbols.

and refusing to have using declarations and directives in your code defeats the purpose of the
namespace mechanism.
You must be kidding. It is "using namespace std;" which defeats the purpose
of the namespace mechanism!

See "C++ Coding Standards" by Sutter & Alexandrescu for a more
reasonable rule regarding the "using" keyword.

[Cy Edmunds]

"Marcus Kwok" <ri******@gehennom.invalid> wrote in message
news:e7**********@news-int.gatech.edu...

Pep <pe*@nowhere.com> wrote:

Marcus Kwok wrote:

Daniel T. <da******@earthlink.net> wrote:
I think the FAQ is completely wrong on this point. "using namespace
std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

Hmm, I tend to agree with this view. Adding "using namespace std" in
source
files is fine as it is local to the coding point whereas adding to
include
files can affect the project in ways not intended.

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migr...namespaces.htm

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

From the cited article:

In short, a good long-term solution for namespace usage should follow at
least these rules:

Namespace Rule #1: Avoid using directives entirely, especially in header
files.

The part of the article recommending using clauses has to do with updating
legacy code. This is a lot different than "Adding "using namespace std" in
source files is fine...".

[Derek]

Pep wrote:

Is it best to include the code "using namespace std;" in the source

Yes.

The argument that you want to avoid namespace conflict is a very weak
one.

The only time you wouldn't want to include "using namespace std;" is
when you are writing code that makes absolutely no use of standard c++
namespace objects.

[Daniel T.]

In article <Bu*******************@twister.nyroc.rr.com>,
"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

In article <e7**********@pop-news.nl.colt.net>, Pep <pe*@nowhere.com>
wrote:

Sumit Rajan wrote:

>
> "Pep" <pe*@nowhere.com> wrote in message
> news:e7**********@pop-news.nl.colt.net...
>> Is it best to include the code "using namespace std;" in the source or
>> should each keyword in the std namespace be qualified by the namespace
>> tag,
>> such as
>>
>> std::cout << "using std namespace" << std::endl;
>>
>> Myself I am not sure which I prefer, it is certainly easier to specify
>> that
>> the std namespace is being used instead of tagging each member of the
>> namespace?
>
>
> This is covered in the FAQ:
> http://www.parashift.com/c++-faq-lit....html#faq-27.5

Whilst I agree with the FAQ in a new project, it does not really address
the
scenario I placed in my reply to Jim Langston. Yes it is possible to
decide at the begginning of a project but badly documented projects which
I
have worked on do not make the distinction very clearly and when the long
time serving inmates of the project leave, they take that sort of
knowledge
with them. In the past I have wasted 3 days on a simple bug simply
because
it was not documented that some of the std entities had been replaced
with
locally defined ones.

Then again maybe I should simply stick to contracts that involve properly
documented designs, yeah right :)
I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

The supposed "problem" of "using namespace std" allowing the compiler
see all the std names isn't a problem at all,

I don't think you have thought this through. What happens when a revised
standard comes out and the standard namespace gets another large injections
of names? For that matter, what happens when you refactor your own code and
introduce a symbol which conflicts with a standard identifier?

The compiler informs me of the issue and I disambiguate the code.
Maintainability is too important to compromise for the sake of avoiding
typing std:: in front of a few symbols.

That is exactly why I think putting std:: in front of all the symbols is
a bad idea. Pre-namespace, each library had to prepend every function
and type in its code with some "unique" symbol, this had to be typed
every-time one used any type or symbol from that library.

The whole point of the namespace mechanism is to remove the need for
those warts, so why on earth would you voluntarily put them right back
in again?

and refusing to have using
declarations and directives in your code defeats the purpose of the
namespace mechanism.

You must be kidding. It is "using namespace std;" which defeats the purpose
of the namespace mechanism!

As I show above, I'm not kidding.

[Daniel T.]

In article <e7**********@news-int2.gatech.edu>,
ri******@gehennom.invalid (Marcus Kwok) wrote:

Daniel T. <da******@earthlink.net> wrote:

I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

I had started to word it much like you did, so I guess we are on the
same page. :-)

[Daniel T.]

In article <e7**********@news-int.gatech.edu>,
ri******@gehennom.invalid (Marcus Kwok) wrote:

Pep <pe*@nowhere.com> wrote:

Marcus Kwok wrote:

Daniel T. <da******@earthlink.net> wrote:
I think the FAQ is completely wrong on this point. "using namespace std"
is fine to use in source files (after all includes,) while no using
directive or declaration should ever be used in a header file.

Yes, I think a generalization of this is that "using directives" are
fine when you can control the scope of the directive. Your situation
above is now a specific case of this, though your wording may be easier
to understand for people who don't know the language extensively yet,
since it is more concrete.

Hmm, I tend to agree with this view. Adding "using namespace std" in source
files is fine as it is local to the coding point whereas adding to include
files can affect the project in ways not intended.

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migr...namespaces.htm

Mr. Sutter later revised his opinion on this matter, which is why I
explicitly referenced his recent book.

[Cy Edmunds]

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

In article <Bu*******************@twister.nyroc.rr.com>,
"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

> In article <e7**********@pop-news.nl.colt.net>, Pep <pe*@nowhere.com>
> wrote:
>
>> Sumit Rajan wrote:
>>
>> >
>> > "Pep" <pe*@nowhere.com> wrote in message
>> > news:e7**********@pop-news.nl.colt.net...
>> >> Is it best to include the code "using namespace std;" in the source
>> >> or
>> >> should each keyword in the std namespace be qualified by the
>> >> namespace
>> >> tag,
>> >> such as
>> >>
>> >> std::cout << "using std namespace" << std::endl;
>> >>
>> >> Myself I am not sure which I prefer, it is certainly easier to
>> >> specify
>> >> that
>> >> the std namespace is being used instead of tagging each member of
>> >> the
>> >> namespace?
>> >
>> >
>> > This is covered in the FAQ:
>> > http://www.parashift.com/c++-faq-lit....html#faq-27.5
>>
>> Whilst I agree with the FAQ in a new project, it does not really
>> address
>> the
>> scenario I placed in my reply to Jim Langston. Yes it is possible to
>> decide at the begginning of a project but badly documented projects
>> which
>> I
>> have worked on do not make the distinction very clearly and when the
>> long
>> time serving inmates of the project leave, they take that sort of
>> knowledge
>> with them. In the past I have wasted 3 days on a simple bug simply
>> because
>> it was not documented that some of the std entities had been replaced
>> with
>> locally defined ones.
>>
>> Then again maybe I should simply stick to contracts that involve
>> properly
>> documented designs, yeah right :)
>
> I think the FAQ is completely wrong on this point. "using namespace
> std"
> is fine to use in source files (after all includes,) while no using
> directive or declaration should ever be used in a header file.
>
> The supposed "problem" of "using namespace std" allowing the compiler
> see all the std names isn't a problem at all,
I don't think you have thought this through. What happens when a revised
standard comes out and the standard namespace gets another large
injections
of names? For that matter, what happens when you refactor your own code
and
introduce a symbol which conflicts with a standard identifier?

The compiler informs me of the issue and I disambiguate the code.

Maintainability is too important to compromise for the sake of avoiding
typing std:: in front of a few symbols.

That is exactly why I think putting std:: in front of all the symbols is
a bad idea. Pre-namespace, each library had to prepend every function
and type in its code with some "unique" symbol, this had to be typed
every-time one used any type or symbol from that library.

The whole point of the namespace mechanism is to remove the need for
those warts,

I think the point is to give the programmer a reasonable way to avoid name
collisions. Namespaces only remove warts if you take the unsafe appoach of
automatically placing a using clause at the top of each of your programs.
Doing this is the functional equivalent of using neither warts nor
namespaces.

so why on earth would you voluntarily put them right back in again?
In old fashioned C interfaces we had to put warts on the names to prevent
collisions. For instance:

mylib_open();
mylib_close();

As you point out, it isn't a great step forward to have to type

mylib::open();
mylib::close();

However, there was never a practice of writing

std_vector<double> x;
std_cout << y;

Hence, putting potentially hundreds of names in your namespace by writing

using namespace std;

seems kind of crazy, at least for new code. (I could see it as a measure for
migrating legacy code.) In effect, namespaces allow us to put warts on all
the standard library names which, given their sheer number, seems like a
damned good idea to me.

I personally don't mind writing

mylib::open();

That, together with a telling header such as

#include "mylib/mylib.h"

gives the reader of the code a pretty good idea of where things are coming
from. And if the namespace is too long there is a mechanism to create an
alias.

> and refusing to have using
> declarations and directives in your code defeats the purpose of the
> namespace mechanism.

You must be kidding. It is "using namespace std;" which defeats the
purpose
of the namespace mechanism!

As I show above, I'm not kidding.

Now I understand the disconnect: we have radically different ideas about the
purpose of namespaces.

[Pep]

Howard wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Jim Langston wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...
Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

For non trivial code, using std namespace; may be okay, but I never use
it
then either.

The problem with using std namespace; is that it brings everything into
the
unnamed namespace. Usually this doesn't cause problems, until you try
to declare a function or variable or class with the same name as
something else in the std namespace.

This is where I dither over the choice. Given that all c++ programmers
are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace
tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std and
as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.

If you don't really like doing std::cout std::endl etc... just bring
what you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

Yet, as a new developer on a project that has been badly documented and
laid
out over several hundred source files, I might miss the fact that cout
and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

I don't find it particularly inconvient to type the extra characters for
things lke std::cout, so most of the time I just type it out.

But if I'm working with other developers, I'll often put using statements
(such as "using std::cout;") at the top of a given function. That way,
the using statements for that function are right there at the entry to the
function, where other developers can immediately see what the following
code
is referring to. (Which is good self-documentation!)

-Howard

Agreed that this is a reasonable approach that I have adopted in the past
but I think my problems with the namespaces are that I invariably get
drafted in to radically upgrade and support really bad legacy code which
has routines that extend to over 1,000 lines of code in one single method,
I kid you not!

The current project I am maintaining has hundreds of routines like this,
sometimes multiple > 1,000 lines of code per method in one source file!

So at this point you can forgive developers for not noticing anything at the
top of the routine, which in this case I suppose the only safe option is to
either

use the namespace std:: prefix to all enclosed routines

or

insist that std:: namespace is the default for the project and that any
routines, templates or classes used from other namespaces that override the
std:: namespace must be prefixed with the namespace tag

I guess this is going to become one of those legacy support issues when c++
is advanced to something new ;)

[Pep]

Cy Edmunds wrote:

"Howard" <al*****@hotmail.com> wrote in message
news:84*******************@bgtnsc04-news.ops.worldnet.att.net...

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Jim Langston wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...
> Is it best to include the code "using namespace std;" in the source or
> should each keyword in the std namespace be qualified by the namespace
> tag,
> such as
>
> std::cout << "using std namespace" << std::endl;
>
> Myself I am not sure which I prefer, it is certainly easier to specify
> that
> the std namespace is being used instead of tagging each member of the
> namespace?

For non trivial code, using std namespace; may be okay, but I never use
it
then either.

The problem with using std namespace; is that it brings everything into
the
unnamed namespace. Usually this doesn't cause problems, until you try
to
declare a function or variable or class with the same name as something
else in the std namespace.
This is where I dither over the choice. Given that all c++ programmers
are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace
tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std
and as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.

If you don't really like doing std::cout std::endl etc... just bring
what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

Yet, as a new developer on a project that has been badly documented and
laid
out over several hundred source files, I might miss the fact that cout
and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

I don't find it particularly inconvient to type the extra characters for
things lke std::cout, so most of the time I just type it out.

But if I'm working with other developers, I'll often put using statements
(such as "using std::cout;") at the top of a given function. That way,
the using statements for that function are right there at the entry to
the function, where other developers can immediately see what the
following
code is referring to. (Which is good self-documentation!)

-Howard

I agree that it is good documentation, but I find it hard to maintain. If
you refactor your code in such a way that the function is no longer used
you have to remember to get rid of your using clause also. Of course it is
not an error to claim to be using something you are not, but it is
misleading.

Cy

It can be hard to maintain but no more than refactoring a deprecated class
such as ostrstream for ostringstream, in both cases you have to find all
occurrences of the item being refactored.

Thanks to everyone for their input on this. I guess it is as most things in
the real world, there are many ways of handling problems each with their
own pros and cons and supporters and detractors :)

[Daniel T.]

In article <7c******************@twister.nyroc.rr.com>,
"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

[snip]

In effect, namespaces allow us to put warts on all the standard
library names which, given their sheer number, seems like a damned
good idea to me.
[snip]
Now I understand the disconnect: we have radically different ideas about the
purpose of namespaces.

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

[Marcus Kwok]

Daniel T. <da******@earthlink.net> wrote:

In article <e7**********@news-int.gatech.edu>,
ri******@gehennom.invalid (Marcus Kwok) wrote:

Here is a good article on namespace usage (especially on adding
namespaces to existing code):

http://www.gotw.ca/publications/migr...namespaces.htm

Mr. Sutter later revised his opinion on this matter, which is why I
explicitly referenced his recent book.

Oh ok, thanks for the info. I will check it out sometime.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Cy Edmunds]

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

In article <7c******************@twister.nyroc.rr.com>,
"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

[snip]

In effect, namespaces allow us to put warts on all the standard
library names which, given their sheer number, seems like a damned
good idea to me.

[snip]

Now I understand the disconnect: we have radically different ideas about
the
purpose of namespaces.

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

Cy

[Daniel T.]

"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

"Daniel T." <da******@earthlink.net> wrote:

"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

[snip]

In effect, namespaces allow us to put warts on all the standard
library names which, given their sheer number, seems like a damned
good idea to me.

[snip]

Now I understand the disconnect: we have radically different ideas about
the
purpose of namespaces.

So you think the reason the namespace mechanism was introduced is so
that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

[Jim Langston]

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Jim Langston wrote:

"Pep" <pe*@nowhere.com> wrote in message
news:e7**********@pop-news.nl.colt.net...

Is it best to include the code "using namespace std;" in the source or
should each keyword in the std namespace be qualified by the namespace
tag,
such as

std::cout << "using std namespace" << std::endl;

Myself I am not sure which I prefer, it is certainly easier to specify
that
the std namespace is being used instead of tagging each member of the
namespace?

For non trivial code, using std namespace; may be okay, but I never use
it
then either.

The problem with using std namespace; is that it brings everything into
the
unnamed namespace. Usually this doesn't cause problems, until you try to
declare a function or variable or class with the same name as something
else in the std namespace.

This is where I dither over the choice. Given that all c++ programmers
are
aware of the std namespace and expects it to provide the standard c/c++
enities, shouldn't we place our overrides in a application specific
namespace and then qualify the use of the routines with the namespace tag?

i.e.

namespace foo
{
int atol(const char* val)
{
return(std::atol(val) * 100);
}
}

cout << foo::atol("12") << endl;

This is very clearly calling atol from a different namespace than std and
as
a new developer on the project I would immediately be suspect of the
routine and would want to check out it's functionality.

If you don't really like doing std::cout std::endl etc... just bring what
you need into the unnamed namespace.

using std::cout;
using std::endl;

now you can use
cout << "blah blah" << endl;
without bringing in everything else.

Yet, as a new developer on a project that has been badly documented and
laid
out over several hundred source files, I might miss the fact that cout and
endl were brought in like this. As such the mixed used of the imported
cout, imported endl and let's say a locally declared atol might get
confusing as you would naturally assume that the std namespace has been
employed and therefore are using std::atol instead of foo::setw.

Personally, I never use the using statement at all. I always just prefix
std:: as I don't find it that difficult at all. Of course typing 70+ wpm
helps. I find that not using using at all means I never have to worry about
what I'm bringing into the unnamed namespace and never get the hard to find
problems that others run into.

I used to program in C and I had run into the problem of two different
modules using the same function names and it was a pain to deal with. I
wound up hacking one of the modules renaming the functions everywhere. I
was overjoyed to find that C++ has namespaces to get rid of this problem,
and seeing how it's something that's extremely useful I'm going to do
everything I can to make sure I don't short circuit it, which I see as the
using statement as doing.

[Cy Edmunds]

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

"Daniel T." <da******@earthlink.net> wrote:

> "Cy Edmunds" <sp***************@rochester.rr.com> wrote:
>
> [snip]
>> In effect, namespaces allow us to put warts on all the standard
>> library names which, given their sheer number, seems like a damned
>> good idea to me.
>>
> [snip]
>>
>> Now I understand the disconnect: we have radically different ideas
>> about
>> the
>> purpose of namespaces.
>
> So you think the reason the namespace mechanism was introduced is so
> that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the
using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

So you think the committee put namespaces into the language because they are
stupid? Name conflicts are a common problem in large projects.

The problem which doesn't exist is having to type std:: once in a while.

Cy

[Daniel T.]

In article <mK******************@twister.nyroc.rr.com>,
"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

"Daniel T." <da******@earthlink.net> wrote:
> "Cy Edmunds" <sp***************@rochester.rr.com> wrote:
>
> [snip]
>> In effect, namespaces allow us to put warts on all the standard
>> library names which, given their sheer number, seems like a damned
>> good idea to me.
>>
> [snip]
>>
>> Now I understand the disconnect: we have radically different ideas
>> about
>> the
>> purpose of namespaces.
>
> So you think the reason the namespace mechanism was introduced is so
> that the standard library names would have warts?

Of course! It does other useful things, too, all of which have to do with
*adding* warts. It certainly does nothing to remove warts. Consider:

Old way:

#include <iostream.h>
cout << 44;

My way:

#include <iostream>
std::cout << 44; // now we have warts

Your way:

#include <iosteam>
using namespace std;
cout << 44; // same warts (none) as old way

So the net effect of namespaces is to introduce new warts although the
using
clause gives us a way to sort of break even with some extra effort.

In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.
"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

So you think the committee put namespaces into the language because they are
stupid? Name conflicts are a common problem in large projects.

No, I think they put the namespace mechanism into the language so that
library venders wouldn't have to make every-one put warts at the
beginning of all the types used in a program. I explained this already.
The problem which doesn't exist is having to type std:: once in a while.

Well, I guess that depends on how extensively you use standard
components and libraries that actually are in namespaces. If you are
only prepending the namespace "once in a while" I agree with you
completely

[Markus Schoder]

Cy Edmunds wrote:

"Daniel T." <da******@earthlink.net> wrote in message
news:da****************************@news.west.eart hlink.net...

"Cy Edmunds" <sp***************@rochester.rr.com> wrote:

"Daniel T." <da******@earthlink.net> wrote:
> "Cy Edmunds" <sp***************@rochester.rr.com> wrote:
>
> [snip]
>> In effect, namespaces allow us to put warts on all the standard
>> library names which, given their sheer number, seems like a damned
>> good idea to me.
>>
> [snip]
>>
>> Now I understand the disconnect: we have radically different ideas
>> about
>> the
>> purpose of namespaces.
>
> So you think the reason the namespace mechanism was introduced is so
> that the standard library names would have warts?
[snip]
In spite of the unattractive name, I think warts are useful for avoiding
name conflicts as the code evolves.

"As the code evolves" makes it sound like some huge bug-a-boo that you
are somehow magically avoiding by putting "std::" in front of a good
chunk of the code in a cpp file.

This name conflict issue that you are so concerned about, that you add
an extra five plus characters to every reference of every type in your
code is a chimera. The rare instance when it comes up, the compiler
invariably points it out, and is easy to fix. The problem simply doesn't
exist.

So you think the committee put namespaces into the language because they
are stupid? Name conflicts are a common problem in large projects.

The problem which doesn't exist is having to type std:: once in a while.

You seem to miss the point. On the rare occasion were you hit a name
conflict you can use explicit scope resolution to resolve it. This is what
you cannot not do without namespaces.

There is still the risk that new names are introduced in namespace std in
the new standard conflicting with a heavily used name in your project.

I consider this risk however to be fairly small since new names will very
likely be mostly introduced through new header files thus not affecting
existing code.

[Bo Persson]

"Markus Schoder" <a3*************@yahoo.de> skrev i meddelandet
news:449c60a3$0$11067

There is still the risk that new names are introduced in namespace
std in
the new standard conflicting with a heavily used name in your
project.

I consider this risk however to be fairly small since new names will
very
likely be mostly introduced through new header files thus not
affecting
existing code.

Right now new features are being added to existing headers in the
draft for the next standard. New features in their own headers, like
type_traits, are likely to be used by other parts of the standard
library, thus included indirectly.

I consider the risk to be fairly LARGE.
Bo Persson