Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

using namespace std

113 views
Skip to first unread message

arnuld

unread,
Jan 4, 2015, 12:30:12 AM1/4/15
to
I am reading Stroustrup's Tour of C++ where in section 3.3 (Namespaces)
he encourages using /using namespace std/ whereas C++ FAQs say it is a
bad ideas (for the reasons that I find quite logical) and we should use /
std::/ all the time or just use /using st::cout/ etc. Pelsonally I think
I will go with the FAQ but I was just disappointed that Stroustrup did
not mention that how much bad idea it is to dump whole of the namespace
into your program.

He created C++, so whom should I give more preference, Tour of C++ of the
FAQs ? or I did not understand what he is trying to say ?






--
arnuld
http://lispmachine.wordpress.com/

Paavo Helde

unread,
Jan 4, 2015, 2:12:14 AM1/4/15
to
arnuld <sun...@invalid.address> wrote in
news:54a8cfd2$0$284$1472...@news.sunsite.dk:
First I admit I haven't read the Stroustrup's text, just sharing my
opinion about 'using namespace'.

Like everything else in programming, some style decision is not the goal.
The goal is to get something done, which in case of C++ often means
writing software which is maintainable over long time. Software is
maintainable if it is concsise, gives enough detail and does not involve
too many distractions. The namespace prefixes are both the detail and the
distraction, so one has to find some good balance when using them.

IMO, the one-two namespaces which are used heavily in the code could be
used without prefixes to reduce distraction and verbosity, and all other
namespaces should be spelled out for providing the detail. In my code the
heavily used namespaces are my own ones, so std:: is always spelled out,
but I gather it may be different in some other code and 'using namespace
std;' could be a good idea in some code (like in example code
demonstrating the use of standard library).

That said, 'using namespace' should never appear in a header file, to not
force its decision about the balance upon other source code files.

hth
Paavo

Marcel Mueller

unread,
Jan 4, 2015, 3:13:53 AM1/4/15
to
On 04.01.15 06.29, arnuld wrote:
> I am reading Stroustrup's Tour of C++ where in section 3.3 (Namespaces)
> he encourages using /using namespace std/ whereas C++ FAQs say it is a
> bad ideas (for the reasons that I find quite logical) and we should use /
> std::/ all the time or just use /using st::cout/ etc. Pelsonally I think
> I will go with the FAQ but I was just disappointed that Stroustrup did
> not mention that how much bad idea it is to dump whole of the namespace
> into your program.

Well, the implementation of the namespace concept in C++ has advantages
and disadvantages. Using them consequently avoids name clashes to a high
degree. And fortunately the standard library has only a short namespace
unlike Java or CLI. But it is still a code blow up and I hate this.
Unfortunately the C++ header files are not very compatible to the using
statement. The usings in headers 'infect' the entire program. Unlike
Java they do not only apply to the current file. So you cannot
reasonably use them in your headers.

Practically, name clashes are not always that likely. If I have small
projects I do not care about the rules, place using namespace standard
into a common header and never think about namespaces again. But for
larger projects this is no serious option. There you have to live with
std:: at least in the headers.


Marcel

Öö Tiib

unread,
Jan 4, 2015, 3:32:19 PM1/4/15
to
On Sunday, January 4, 2015 7:30:12 AM UTC+2, arnuld wrote:
> I am reading Stroustrup's Tour of C++ where in section 3.3 (Namespaces)
> he encourages using /using namespace std/

That tour? https://isocpp.org/images/uploads/2-Tour-Basics.pdf
It seems at 2.4.2 not 3.3 maybe it is different paper or different
version of paper.

> whereas C++ FAQs say it is a
> bad ideas (for the reasons that I find quite logical) and we should use /
> std::/ all the time or just use /using st::cout/ etc. Pelsonally I think
> I will go with the FAQ but I was just disappointed that Stroustrup did
> not mention that how much bad idea it is to dump whole of the namespace
> into your program.

It is a bad idea because namespace 'std' has lot of names in it. The
name clashes will be quite likely. Especially when using in mix with
the likes of 'boost' that often contains same names. The resulting error
messages may be hard to understand.

Clashes are less likely if your software (and libraries that you
use) have major difference in naming. For example if you use only
capitalized names.

> He created C++, so whom should I give more preference, Tour of C++ of the
> FAQs ? or I did not understand what he is trying to say ?

It is important to mention what the line does in a tour because majority
of standard library usage examples you find anywhere in the net use it.
Also most of Stroustrup's own examples use it.

JiiPee

unread,
Jan 4, 2015, 3:35:16 PM1/4/15
to
so std:: in the headers and maybe

using std::cout;

int the cpp?

Ian Collins

unread,
Jan 4, 2015, 3:41:49 PM1/4/15
to
That's a fair approach.

--
Ian Collins
Message has been deleted

Jorgen Grahn

unread,
Jan 4, 2015, 4:49:11 PM1/4/15
to
On Sun, 2015-01-04, 嘱 Tiib wrote:
> On Sunday, January 4, 2015 7:30:12 AM UTC+2, arnuld wrote:
>> I am reading Stroustrup's Tour of C++ where in section 3.3 (Namespaces)
>> he encourages using /using namespace std/
>
> That tour? https://isocpp.org/images/uploads/2-Tour-Basics.pdf
> It seems at 2.4.2 not 3.3 maybe it is different paper or different
> version of paper.

...

>> He created C++, so whom should I give more preference, Tour of C++ of the
>> FAQs ? or I did not understand what he is trying to say ?
>
> It is important to mention what the line does in a tour because majority
> of standard library usage examples you find anywhere in the net use it.
> Also most of Stroustrup's own examples use it.

To be more explicit: if this is the text arnuld read:

The simplest way to access a name in another namespace is to
qualify it with the namespace name [...] To gain access to all the
names in the standard-library namespace, we can use a
using-directive:

using namespace std;

Stroustrup just shows that you /can/ do that, not that you /should/.
It's just a tour of the language: I think you're just supposed to
learn there is something called namespaces, so you know there's such a
tool in the language.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Mike Austin

unread,
Jan 4, 2015, 4:55:34 PM1/4/15
to
Using boost more lately, I agree that importing whole namespaces is not
a good idea. I do wish C++ has a more terse way of importing, such as:

using std { cout, endl };
using boost { tuple, variant };

Currently, it looks more like this:

using std::cout; using std::endl;
using boost::tuple; using boost::variant;

Another option is nesting namespaces:

namespace iostream {
using std::cout;
using std::endl;
}

using iostream;

Actually, I might just start using that :)

Mike

Geoff

unread,
Jan 4, 2015, 7:51:39 PM1/4/15
to
It's a crutch.

It's a habit acquired from reading or writing examples of code as a
teaching tool. In those contexts it's meant to help clarify the points
being taught in the example code but it's not meant to be used
routinely in "production code" unless you never bring in another
namespace. Small, trivial example programs or single-unit programs are
such cases.

Expect to be criticized for using it if you post a code example with a
question in the news groups as someone will always point out that you
should not use it. They can't refrain from doing so. But their intent
is to break the student of the habit of using the crutch as soon as
possible in their career and to acclimate that student to the proper
use of namespaces.

woodb...@gmail.com

unread,
Jan 5, 2015, 12:45:22 AM1/5/15
to
I think you forgot the namespace keyword there.
And that looks like an interesting idea.


Brian
Ebenezer Enterprises - "Yeshua (aka Jesus) said to
him, "I am the way, and the truth, and the life;
no one comes to the Father but through Me." John 14:6

http://webEbenezer.net

woodb...@gmail.com

unread,
Jan 5, 2015, 1:08:27 AM1/5/15
to
On Sunday, January 4, 2015 3:21:04 PM UTC-6, Stefan Ram wrote:
> arnuld <sun...@invalid.address> writes:
> >I am reading Stroustrup's Tour of C++ where in section 3.3 (Namespaces)
> >he encourages using /using namespace std/ whereas C++ FAQs say it is a
> >bad ideas (for the reasons that I find quite logical) and we should use /
>
> It depends on the grade of the code:
>
> When one is writing a small throwaway program where
> maintainability is not important, one can use it.
>
> For code that has a large expected lifetime and needs to be
> robust, one should not use it. I call that »library-grade code«.
>

That doesn't seem like a good name to me because there
are executables that are hoped to be enduring. I don't
have another suggestion, but think it would be confusing
to use that term with regard to executables.


Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net

Paavo Helde

unread,
Jan 5, 2015, 1:15:11 AM1/5/15
to
Mike Austin <sp...@null.net> wrote in
news:4LednYVD3IlQKzTJ...@giganews.com:

> Using boost more lately, I agree that importing whole namespaces is
> not a good idea.

With boost, the namespace names are really too long. Fortunately these can
be shortened:

namespace bnu = boost::numeric::ublas;
namespace bfs = boost::filesystem;

bfs::path x;
bnu::matrix<double> y;

JiiPee

unread,
Jan 5, 2015, 2:25:11 AM1/5/15
to
you should suggest this to the commitea !

Jorgen Grahn

unread,
Jan 5, 2015, 3:06:07 AM1/5/15
to
I think I would have preferred to shorten them to "ublas" and
"filesystem" (or "fs"). For someone studying your program, it's soon
obvious that you're using Boost, and then the boost prefix becomes
redundant. And even I know "ublas" deals with linear algebra, so
"numeric" becomes redundant too.

But yeah, this is one of those areas where people have different
preferences.

Öö Tiib

unread,
Jan 5, 2015, 4:30:00 AM1/5/15
to
When I use some particular library name so lot that code feels too full
of 'std::' (or 'boost::') then I find myself more often replacing names
with more fitting to context (and style) alias or thin wrapper instead
of importing the names exactly. It seems to be bit more maintainable,
extendable, portable, unit-testable and easier to debug that way.
Compilers tend to optimize aliasing and thin wrappers out so no hit to performance.

Maintainability/extendability: What if I want to replace that
'std::vector<std::string>' with 'std::deque<std::string>' or class 'Names'
later? Lot of things to search and to change later if it was used like
that explicitly. 'vector<string>' is only half way. typedef it as 'Names'
right away. Lot less to type also more readable (than 'auto') immediately
but YMMV.

Portability: There are always little differences between most mundane
things per platform. Be it 'snprintf' or 'isnan' ... not exactly same
everywhere.

unit-testability: It is usually easier to inject special mocks if there
are mine own names.

easier to debug: It is easier to insert break-points or debug-time
checks to thin wrappers.

Vincenzo Mercuri

unread,
Jan 5, 2015, 9:09:30 AM1/5/15
to
..

He doesn't really encourage using "using namespace std;".

First, in the section you are referring to he illustrates the
advantage of declaring the "My_code" namespace to "make sure
that my names do not conflict with the standard-library names
in namespace std" and then he says: "we can use a using-directive".

That sounds like an option, not a suggestion.

Second, in section 6.3, page 73, he says: "It is generally in
poor taste to dump every name from a namespace into the global
namespace. However, in this book, I use the standard library
exclusively and it is good to know what it offers."

Sorry for quoting directly from the book, but I find these
parts relevant to answer to the OP.

--
Vincenzo Mercuri

Vincenzo Mercuri

unread,
Jan 5, 2015, 9:16:29 AM1/5/15
to
Il 04/01/2015 22:49, Jorgen Grahn ha scritto:
..
> To be more explicit: if this is the text arnuld read:
>
> The simplest way to access a name in another namespace is to
> qualify it with the namespace name [...] To gain access to all the
> names in the standard-library namespace, we can use a
> using-directive:
>
> using namespace std;
>
> Stroustrup just shows that you /can/ do that, not that you /should/.
> It's just a tour of the language: I think you're just supposed to
> learn there is something called namespaces, so you know there's such a
> tool in the language.
>

Oops, I quoted that part from the book as well,
I didn't notice you already did :) Pardon.

--
Vincenzo Mercuri

Jorgen Grahn

unread,
Jan 5, 2015, 9:36:09 AM1/5/15
to
No problem: you did it better. And after all this "OMG Stroustrup
says we should all be 'using namespace std'!" it doesn't hurt to
explain twice that he doesn't, really.

BTW, I don't think anyone minds us quoting the book from a copyright
perspective. "Fair use" was invented for exactly this scenario.

Vincenzo Mercuri

unread,
Jan 5, 2015, 9:45:05 AM1/5/15
to
Il 05/01/2015 15:35, Jorgen Grahn ha scritto:
> On Mon, 2015-01-05, Vincenzo Mercuri wrote:
..
>> Oops, I quoted that part from the book as well,
>> I didn't notice you already did :) Pardon.
>
> No problem: you did it better. And after all this "OMG Stroustrup
> says we should all be 'using namespace std'!" it doesn't hurt to
> explain twice that he doesn't, really.
>
> BTW, I don't think anyone minds us quoting the book from a copyright
> perspective. "Fair use" was invented for exactly this scenario.

Yes, I just felt a bit uncomfortable when I opened the book
and copied the text. I wasn't aware of this legal term actually,
thanks for pointing that out.

--
Vincenzo Mercuri

Mike Austin

unread,
Jan 5, 2015, 3:35:10 PM1/5/15
to
That is also a very good habit. It also helps clean up the nested
template ">>" issues. Another example to complement yours:

namespace UI {

using std::shared_ptr; // Can change to boost if no C++11 support
using std::vector; // Can change to list or deque if needed

struct View {
typedef shared_ptr<View> Ptr; // Hide the implementation
typedef vector<View::Ptr> ChildView; // Again, hide details
};

}

Mike
0 new messages