Why do we have to define a namespace with string header?

[bgeneto]

I know that it's a very basic question, but I can't figure out or find
an answer to why do we have to specify a namespace, like this

#include<string >
using namespace std;

when using the standard string library? Is this really necessary, why?
Thanks,

Bernhard Enders.

[Ian Collins]

bgeneto wrote:

I know that it's a very basic question, but I can't figure out or find
an answer to why do we have to specify a namespace, like this

#include<string >
using namespace std;

when using the standard string library? Is this really necessary, why?
Thanks,

Because the standard library functions are declared in the namespace std.

You have to fully qualify something declared in a namespace, otherwise
the compiler won't find the symbol.

I'd avoid the blanket 'using namespace' directive and either use fully
qualified names (line std::cout) or use specific using directives for
the items you want to use from the namespace (using std::cout; for
example).

--
Ian Collins.

[Alan Johnson]

bgeneto wrote:

I know that it's a very basic question, but I can't figure out or find
an answer to why do we have to specify a namespace, like this

#include<string >
using namespace std;

when using the standard string library? Is this really necessary, why?
Thanks,

Bernhard Enders.

When creating a library, it is generally a good idea to put any symbols
you define in their own namespace. Doing so severely decreases the
chances that names that you use will conflict with names in the library
you write conflicting with names in others' libraries. You might say
the designers of the C++ Standard Library were just following good style
and setting a good example by putting all their symbols in namespace
std.

--
Alan Johnson

[bgeneto]

Thanks for your explanation, if I understand well the string class and
possibly it's methods are defined in the namespace std within the
standard header <string>. If so, what is the point in doing this? Is it
any better compared to the old school? std sounds like a scope to me,
but what do we have defined without the scope std? No class, no
methods, nothing?
About your 'suggestion' to use full qualified names, I figure that I
must also use std::string in addition to std::cout, std::cin, etc... a
little cumbersome, no?

Thanks one more time,

Bernhard Enders.

[Ian Collins]

bgeneto wrote:

Thanks for your explanation, if I understand well the string class and
possibly it's methods are defined in the namespace std within the
standard header <string>. If so, what is the point in doing this? Is it
any better compared to the old school? std sounds like a scope to me,
but what do we have defined without the scope std? No class, no
methods, nothing?
About your 'suggestion' to use full qualified names, I figure that I
must also use std::string in addition to std::cout, std::cin, etc... a
little cumbersome, no?

Cumbersome, but it avoids name collisions between symbols form the
standard library and others. That's why the standard library is in its
own namespace.

The 'old school' (and current C) resolved naming issues by using more
verbose names in an attempt to avoid ambiguities. At least with
namespaces you can dispense with the namespace prefix with an
appropriate using directive.

--
Ian Collins.

[Phlip]

bgeneto wrote:

Thanks for your explanation, if I understand well the string class and
possibly it's methods are defined in the namespace std within the
standard header <string>. If so, what is the point in doing this?

The general set of keywords for C++ were invented in the 1980s.

The Standard Library - the most common and most useful things to do /with/
those keywords - was ratified in 1997.

This was a good thing because the library had time to mature.

But the new language specification had to preserve over a decade of legacy
code. The language committees could not tell everyone, "some of your
functions will now disappear, some will change their behavior, and some will
break your programs now". People would simply reject Standard C++, and keep
using the "ARM C++" and its defacto standard.

So the committee fixed this in one move by putting everything in The
Standard Library into one big namespace. Legacy code that did not declare
this namespace could continue to use their legacy libraries. You might find
your C++ implementation still contains files such as "iostream.h ".

(Worse, code can also mix-and-match legacy and standard code. The less said
about that the better.)

So, if you need strings or "STL" containers, import their namespace. This is
a very minor detail of well-structured code.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Alan Johnson]

bgeneto wrote:

About your 'suggestion' to use full qualified names, I figure that I
must also use std::string in addition to std::cout, std::cin, etc... a
little cumbersome, no?

Within a source file it doesn't matter too much. In that context you
know everything you need to know to tell if it is safe to issue a
'using' directive. It is still my personal preference to explicitly
name which symbols I'll be using. Example:
using std::cout ;
using std::endl ;

In a header file it is best to avoid a 'using' directive that brings
something into the global namespace, as you don't know when and where
that header will get included, and whether or not your 'using'
directives are going to cause trouble for the person doing the
including.

--
Alan Johnson

[P.J. Plauger]

"Alan Johnson" <al****@no.spam .stanford.edu> wrote in message
news:e3******** **@news.Stanfor d.EDU...

bgeneto wrote:

I know that it's a very basic question, but I can't figure out or find
an answer to why do we have to specify a namespace, like this

#include<string >
using namespace std;

when using the standard string library? Is this really necessary, why?
Thanks,

Bernhard Enders.

When creating a library, it is generally a good idea to put any symbols
you define in their own namespace. Doing so severely decreases the
chances that names that you use will conflict with names in the library
you write conflicting with names in others' libraries. You might say
the designers of the C++ Standard Library were just following good style
and setting a good example by putting all their symbols in namespace
std.

You might say that, if it were true. Unfortunately, the Standard C++
library incorporates the Standard C library and the old cfront iostreams
library, both of which were born before namespaces were invented. Thus,
practically *every* pre-standard C++ program broke. Of course, you can
patch most programs by changing a few header names and adding the
notorious "using namespace std", but the latter is actively discouraged
by those who believe in "good style".

Even with newly written code, namespace std causes problems, mostly
because not everything really lives there. Of course, you have some
simple rules:

-- If a name is all caps, it must be a macro, so you don't write std::
in front of it (except for FILE).

-- If a name is all lowercase, it must be a function or object, so
you must write std:: in front of it (except for assert, errno, and
setjmp).

-- If a name begins with an underscore, it must be reserved to the
implementation, so you shouldn't use it (except for _IOFBF, _IOLBF,
and _IONBF).

-- There are no names with mixed case (except for the macro L_tmpnam,
and more recently the function _Exit).

-- Otherwise, all names are in namespace std (except for those in
std::relops).

-- It is therefore safe to recycle a name from the Standard C library
as your own name with external linkage (as long as it's not in either
namespace std or the global namespace, or has extern "C" linkage).

Got all that?

It would have been far better to leave the Standard C++ library in
the global namespace, where it was born and grew up. You can still
use namespaces to protect your own code, and that is indeed good
style. But nobody seems to teach that.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[P.J. Plauger]

"Phlip" <ph******@yahoo .com> wrote in message
news:lQ******** *********@newss vr27.news.prodi gy.net...

bgeneto wrote:

Thanks for your explanation, if I understand well the string class and
possibly it's methods are defined in the namespace std within the
standard header <string>. If so, what is the point in doing this?
The general set of keywords for C++ were invented in the 1980s.

And many more were added during "standardizatio n" in the 1990s.
And *lots* more library names (which are not keywords) were added
as well.
The Standard Library - the most common and most useful things to do /with/
those keywords - was ratified in 1997.

This was a good thing because the library had time to mature.
Some of it. And parts of it were paper tigers that were standardized
before they were ever implemented.
But the new language specification had to preserve over a decade of legacy
code. The language committees could not tell everyone, "some of your
functions will now disappear, some will change their behavior, and some
will break your programs now". People would simply reject Standard C++,
and keep using the "ARM C++" and its defacto standard.
But that's exactly what the C++ committee did do.
So the committee fixed this in one move by putting everything in The
Standard Library into one big namespace. Legacy code that did not declare
this namespace could continue to use their legacy libraries. You might
find your C++ implementation still contains files such as "iostream.h ".
It's nice to think that the C++ committee wisely took a new departure
and made a point of staying out of the way of old library naming
practices, but this was not their goal in adding namespace std and
the new headers. It was the *vendors* who wisely retained the legacy
headers for many years.
(Worse, code can also mix-and-match legacy and standard code. The less
said about that the better.)
Maybe, but quite a lot *had* to be said about it, by those of us who had
to support customers through a decade of transition. You will *still*
see regular postings on these newsgroups along the lines of, "I included
<string>, so why isn't class string defined?"
So, if you need strings or "STL" containers, import their namespace. This
is a very minor detail of well-structured code.

I agree that importing the entire std namespace is often the best way
to repair the damage, but I'm in a tiny minority.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Phlip]

P.J. Plauger wrote:

The general set of keywords for C++ were invented in the 1980s.

And many more were added during "standardizatio n" in the 1990s.
And *lots* more library names (which are not keywords) were added
as well.

The point was the time delay between establishing enough of the core
language to write programs, and establishing a stable library.

The Standard Library - the most common and most useful things to do
/with/ those keywords - was ratified in 1997.

This was a good thing because the library had time to mature.

Some of it. And parts of it were paper tigers that were standardized
before they were ever implemented.

I'm sure some people could have said the exact right thing in fewer words,
but I couldn't. The question was why is the standard library inside
namespace std...

But the new language specification had to preserve over a decade of
legacy code. The language committees could not tell everyone, "some of
your functions will now disappear, some will change their behavior, and
some will break your programs now". People would simply reject Standard
C++, and keep using the "ARM C++" and its defacto standard.

But that's exactly what the C++ committee did do.

....and you are gainsaying minor details. Of course The Standard broke some
existing code, just as The C Standard broke some existing code.

So the committee fixed this in one move by putting everything in The
Standard Library into one big namespace. Legacy code that did not declare
this namespace could continue to use their legacy libraries. You might
find your C++ implementation still contains files such as "iostream.h ".

It's nice to think that the C++ committee wisely took a new departure
and made a point of staying out of the way of old library naming
practices, but this was not their goal in adding namespace std and
the new headers. It was the *vendors* who wisely retained the legacy
headers for many years.

Yet if they had not added namespace std, the Standard language would have
been much harder to adopt for billions of lines of legacy code. So it's the
same difference, and it's an adequate way to explain the namespace std
system to a newbie.

(Worse, code can also mix-and-match legacy and standard code. The less
said about that the better.)

Maybe, but quite a lot *had* to be said about it, by those of us who had
to support customers through a decade of transition. You will *still*
see regular postings on these newsgroups along the lines of, "I included
<string>, so why isn't class string defined?"

That's not mix-and-match.

So, if you need strings or "STL" containers, import their namespace. This
is a very minor detail of well-structured code.

I agree that importing the entire std namespace is often the best way
to repair the damage, but I'm in a tiny minority.

I tried to say "import them from their namespace".

http://www.janko.at/Humor/Computerwe...pace%20std.htm

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!