473,883 Members | 1,681 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 4138
Pep
Howard wrote:

"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


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 ;)

Jun 22 '06 #21
Pep
Cy Edmunds wrote:

"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


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 :)

Jun 22 '06 #22
In article <7c************ ******@twister. nyroc.rr.com>,
"Cy Edmunds" <sp************ ***@rochester.r r.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?
Jun 22 '06 #23
Daniel T. <da******@earth link.net> wrote:
In article <e7**********@n ews-int.gatech.edu> ,
ri******@gehenn om.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
Jun 22 '06 #24

"Daniel T." <da******@earth link.net> wrote in message
news:da******** *************** *****@news.west .earthlink.net. ..
In article <7c************ ******@twister. nyroc.rr.com>,
"Cy Edmunds" <sp************ ***@rochester.r r.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
Jun 22 '06 #25
"Cy Edmunds" <sp************ ***@rochester.r r.com> wrote:
"Daniel T." <da******@earth link.net> wrote:
"Cy Edmunds" <sp************ ***@rochester.r r.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.
Jun 22 '06 #26

"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.


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.
Jun 23 '06 #27

"Daniel T." <da******@earth link.net> wrote in message
news:da******** *************** *****@news.west .earthlink.net. ..
"Cy Edmunds" <sp************ ***@rochester.r r.com> wrote:
"Daniel T." <da******@earth link.net> wrote:
> "Cy Edmunds" <sp************ ***@rochester.r r.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
Jun 23 '06 #28
In article <mK************ ******@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. ..
"Cy Edmunds" <sp************ ***@rochester.r r.com> wrote:
"Daniel T." <da******@earth link.net> wrote:
> "Cy Edmunds" <sp************ ***@rochester.r r.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
Jun 23 '06 #29
Cy Edmunds wrote:
"Daniel T." <da******@earth link.net> wrote in message
news:da******** *************** *****@news.west .earthlink.net. ..
"Cy Edmunds" <sp************ ***@rochester.r r.com> wrote:
"Daniel T." <da******@earth link.net> wrote:
> "Cy Edmunds" <sp************ ***@rochester.r r.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.

Jun 23 '06 #30

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
9940
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
1
10847
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
10415
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
9574
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...
0
7128
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5797
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
5991
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4220
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3232
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.