473,883 Members | 1,798 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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?

Jun 21 '06
30 4140

"Pep" <pe*@nowhere.co m> wrote in message
news:e7******** **@pop-news.nl.colt.ne t...
Jim Langston wrote:
"Pep" <pe*@nowhere.co m> wrote in message
news:e7******** **@pop-news.nl.colt.ne t...
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::ato l(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


Jun 21 '06 #11
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

Jun 21 '06 #12

"Howard" <al*****@hotmai l.com> wrote in message
news:84******** ***********@bgt nsc04-news.ops.worldn et.att.net...

"Pep" <pe*@nowhere.co m> wrote in message
news:e7******** **@pop-news.nl.colt.ne t...
Jim Langston wrote:
"Pep" <pe*@nowhere.co m> wrote in message
news:e7******** **@pop-news.nl.colt.ne t...
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::ato l(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
Jun 21 '06 #13

"Daniel T." <da******@earth link.net> wrote in message
news:da******** *************** *****@news.west .earthlink.net. ..
In article <e7**********@p op-news.nl.colt.ne t>, Pep <pe*@nowhere.co m>
wrote:
Sumit Rajan wrote:
>
> "Pep" <pe*@nowhere.co m> wrote in message
> news:e7******** **@pop-news.nl.colt.ne t...
>> 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.

Jun 21 '06 #14

"Marcus Kwok" <ri******@gehen nom.invalid> wrote in message
news:e7******** **@news-int.gatech.edu. ..
Pep <pe*@nowhere.co m> wrote:
Marcus Kwok wrote:
Daniel T. <da******@earth link.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...".
Jun 21 '06 #15
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.

Jun 21 '06 #16
In article <Bu************ *******@twister .nyroc.rr.com>,
"Cy Edmunds" <sp************ ***@rochester.r r.com> wrote:
"Daniel T." <da******@earth link.net> wrote in message
news:da******** *************** *****@news.west .earthlink.net. ..
In article <e7**********@p op-news.nl.colt.ne t>, Pep <pe*@nowhere.co m>
wrote:
Sumit Rajan wrote:

>
> "Pep" <pe*@nowhere.co m> wrote in message
> news:e7******** **@pop-news.nl.colt.ne t...
>> 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.
Jun 21 '06 #17
In article <e7**********@n ews-int2.gatech.edu >,
ri******@gehenn om.invalid (Marcus Kwok) wrote:
Daniel T. <da******@earth link.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. :-)
Jun 21 '06 #18
In article <e7**********@n ews-int.gatech.edu> ,
ri******@gehenn om.invalid (Marcus Kwok) wrote:
Pep <pe*@nowhere.co m> wrote:
Marcus Kwok wrote:
Daniel T. <da******@earth link.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.
Jun 21 '06 #19

"Daniel T." <da******@earth link.net> wrote in message
news:da******** *************** *****@news.west .earthlink.net. ..
In article <Bu************ *******@twister .nyroc.rr.com>,
"Cy Edmunds" <sp************ ***@rochester.r r.com> wrote:
"Daniel T." <da******@earth link.net> wrote in message
news:da******** *************** *****@news.west .earthlink.net. ..
> In article <e7**********@p op-news.nl.colt.ne t>, Pep <pe*@nowhere.co m>
> wrote:
>
>> Sumit Rajan wrote:
>>
>> >
>> > "Pep" <pe*@nowhere.co m> wrote in message
>> > news:e7******** **@pop-news.nl.colt.ne t...
>> >> 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<doub le> 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.
Jun 22 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
1960
by: cppaddict | last post by:
It is typical to put the line: using namespace std; at the top of a file which makes use of std library objects. To take a simple example: #include <iostream> using namespace std;
17
3529
by: beliavsky | last post by:
Many of my C++ programs have the line using namespace std; but the "Accelerated C++" book of Koenig and Moo has many examples where the library names are included one at a time, for example using std::cin; using std::cout;
8
4380
by: Douglas | last post by:
**** Post for FREE via your newsreader at post.usenet.com **** Hello, The following code does not compile if line 3 is uncommented "using namespace std". I do not understand it. Could somebody explain it to me? I am using MSVC 6.0. Thanks a lot,
11
3264
by: snnn | last post by:
On the book <Generic Programming and the STL>( Matthew . H . Austern ),this function is defined as iterator set::begin() const. However, why should a const object returns a non-const iterator? Then, I found, in this book, the semantic of set::iterator is defined as same as set::const_iterator. Both of them must be const! I tried to read the source of GNU STL(version 3.4.1).They were using a red-black tree to implant it (std::set has a...
4
2718
by: Teddy | last post by:
If I use just a STL container such as std::vector in my program. Is "using std::vector;" better than "using namespace std" ? Does "using namespace std" cost ?
13
141299
by: Squid Seven | last post by:
This is just bizarre. for the following snippet of code: #include <string> using std::string; I get the error message:
25
2603
by: samjnaa | last post by:
Please check for sanity and approve for posting at python-dev. In Visual Basic there is the keyword "with" which allows an object- name to be declared as governing the following statements. For example: with quitCommandButton .enabled = true .default = true end with
0
9792
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
1
10848
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10417
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9575
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7972
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5798
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5992
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4221
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3234
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.