Nathan Myers wrote:
>
> Steve Clamage <clamage@eng.sun.com> wrote:
>> ...
>> The C++ Committee voted overwhelmingly in favor of a single
>> namespace that included the C library in each of several votes
>> that were taken over the course of development of the standard.
>
> The above is an admirably clear and evenhanded exposition on a topic
> where I know Steve has a definite opinion.  My only quibble would be
> to remind the reader that the number of lower-case macros is very
> small.

But the number of lowercase standard class and template names is
fairly large, which is annoying.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

clamage@eng.sun.com (Steve Clamage) wrote in comp.std.c++:
>
>scorp@btinternet.com (Dave Harris) writes:
>>brahms@mindspring.com (Stan Brown) wrote:
>>> Since a common implementation of the xxxx.h headers is
>>>  #include <cmath>      // Impl
>>>  using namespace std;
>
>>Really? My local implementation doesn't use that. I have trouble believing
>>any does, because as you say, it massively pollutes the namespace in an
>>uncontrolled way.
>
>It also is not a valid implementation, because including <math.h>
>(or whatever) would then dump all the members of namespace std
>into the global namespace of your program.

Right. I tried to say that in my original article, but since several
people have felt the need to post that it's invalid I guess I must not
have made it clear that I too think it's invalid.

However, I don't think I should have called that implementation "common".
"Plausible" or "naive" would probably have been a better adjective. Such
an implementation is appealing in its simplicity, but as we all agree it
does not pass muster with what the standard says the xxxx.h headers
should do, which is to add only their own members (not all of std) to
the global namespace.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/

Signature down for repairs. Sorry for the inconvenience.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

scorp@btinternet.com (Dave Harris) writes:


>brahms@mindspring.com (Stan Brown) wrote:
>> Since a common implementation of the xxxx.h headers is
>>  #include <cmath>      // Impl
>>  using namespace std;

>Really? My local implementation doesn't use that. I have trouble believing
>any does, because as you say, it massively pollutes the namespace in an
>uncontrolled way.

It also is not a valid implementation, because including <math.h>
(or whatever) would then dump all the members of namespace std
into the global namespace of your program.

#include <iostream>
#include <math.h>

int cout;

int main() {
 cout = 1;
}

This valid (if ill-advised) program would not compile if <math.h>
contained the using-directive.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

clamage@eng.sun.com (Steve Clamage) wrote in comp.std.c++:
>brahms@mindspring.com (Stan Brown) writes:
>>I have a question about the evolution of namespaces after 1994, when D&E
>>was published. Specifically, why is everything in the standard library in
>>namespace std? ...
>
>The question has at least three parts, which I'll discuss:
>no namespace vs one namespace vs many smaller namespaces.

Thanks for answering my question, with rationale and historical
perspective.

By the way, I never meant to raise the "no namespace" possibility. It
seems obvious to me that namespace(s) is better than no namespaces. (I'm
always a little nervous when claiming anything is "obvious". :-)

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/

"It's my opinion, and it's very true."


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern <austern@sgi.com> writes:

> scorp@btinternet.com (Dave Harris) writes:
>
> > brahms@mindspring.com (Stan Brown) wrote:
> > > Since a common implementation of the xxxx.h headers is
> > >  #include <cmath>      // Impl
> > >  using namespace std;
> >
> > Really? My local implementation doesn't use that. I have trouble believing
> > any does, because as you say, it massively pollutes the namespace in an
> > uncontrolled way. Does it have any advantage over:
> >
> >     cxxxx
> >         namespace std {
> >         #include <xxxx.h>
> >         }
> >
> > Generally I would avoid "using namespace xxx" at global scope in headers.
>
> It comes closer to being conforming.  Names in the <cfoo> headers are
> required to be defined in namespace std only, and names in the <foo.h>
> headers are required to be defined in namespace std and then brought
> into the global namespace.  (See D.5/2 in the C++ standard.)  There
> are some cases, like structs, where the subtle distinctions matter.

Rereading my post, I realize that saying "closer to being conforming"
makes it sound as if I endorse implementing <foo.h> as
  #include <cfoo>
  using namespace std;
I don't, of course.  It's a terrible idea, for just the reasons Dave
said.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

brahms@mindspring.com (Stan Brown) wrote:
> Since a common implementation of the xxxx.h headers is
>  #include <cmath>      // Impl
>  using namespace std;

Really? My local implementation doesn't use that. I have trouble believing
any does, because as you say, it massively pollutes the namespace in an
uncontrolled way. Does it have any advantage over:

    cxxxx
        namespace std {
        #include <xxxx.h>
        }

Generally I would avoid "using namespace xxx" at global scope in headers.


> [D&E:} "Common taste (including mine) favors the use of many smaller
> namespaces over putting really major pieces of code into a single
> namespace."

In my experience, namespaces are wonderful but are best used sparingly.
Otherwise they just get in the way. I use them mainly where there is a
real chance of getting name clashes.

If you find yourself writing file_open(), window_open(), prefixing each
name with its module, then that's a hint you should move to file::open()
and window::open(). The key thing here is that the namespace makes the
unqualified name shorter.

If we look at the standard library, they mostly don't work like that. OK,
we have strcmp() and memcmp(), and maybe that's an argument for std::cmp()
mem::cmp(), but it's not very compelling. We have fopen(), but we don't
want f::open() and file::fopen() would be redundant. File::open() would be
nice, but breaks backwards compatibility.

For historical reasons the std names already work together; they don't
have clashes. So the usual reason for multiple namespaces doesn't arise.

By the way, if it did use multiple namespaces why do you suppose it would
be stdio::printf rather than std::io::printf? That is the approach taken
with std::rel_ops. The advantage is that the whole standard need add only
one name to the global namespace. Good hygiene.

I suspect if the std library were being designed from scratch, without
influence from C or earlier C++, it might have been done differently.
Perhaps then we would have std::string::compare().

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <clamage@eng.sun.com> wrote:
>>3. Why is the part of the library inherited from C in the namespace?
>
>A controversial topic. I'll try to present a balanced view of
>the arguments on both sides.
>
>Pro: The entire library is available in namespace std. You don't
>have to remember which elements come from C and which are unique
>to C++. You can always use the prefix "std::" -- except for macros,
>which blunts this argument. In addition, the C part of the library
>also contains a LOT of names, and we have the option of reducing
>the name conflicts -- again, except for macros.
>
>Con: "Everybody knows" the names that come from C -- except for
>new programmers who start with C++ and don't learn C explicitly.
>The macros can't be put into a namespace anyway. Implementation
>is more difficult, where the C++ implementer doesn't own the C headers.
>
>The C++ Committee voted overwhelmingly in favor of a single
>namespace that included the C library in each of several votes
>that were taken over the course of development of the standard.

The above is an admirably clear and evenhanded exposition on a topic
where I know Steve has a definite opinion.  My only quibble would be
to remind the reader that the number of lower-case macros is very small.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

scorp@btinternet.com (Dave Harris) writes:

> brahms@mindspring.com (Stan Brown) wrote:
> > Since a common implementation of the xxxx.h headers is
> >  #include <cmath>      // Impl
> >  using namespace std;
>
> Really? My local implementation doesn't use that. I have trouble believing
> any does, because as you say, it massively pollutes the namespace in an
> uncontrolled way. Does it have any advantage over:
>
>     cxxxx
>         namespace std {
>         #include <xxxx.h>
>         }
>
> Generally I would avoid "using namespace xxx" at global scope in headers.

It comes closer to being conforming.  Names in the <cfoo> headers are
required to be defined in namespace std only, and names in the <foo.h>
headers are required to be defined in namespace std and then brought
into the global namespace.  (See D.5/2 in the C++ standard.)  There
are some cases, like structs, where the subtle distinctions matter.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I've been reading Stroustrup's /D&E/ and enjoying it very much.

I have a question about the evolution of namespaces after 1994, when D&E
was published. Specifically, why is everything in the standard library in
namespace std? I always took std for granted until I got to the
Namespaces chapter of D&E. Let me explain why I now wonder about it.

On page 406, in "17.4.1 Views on Namespace Use", Stroustrup talks about
when explicit qualification is useful and when using declarations (or
even directives) are useful.

"... The name of a library plus the name of a function often makes the
meaning of an expression obvious. For these reasons, explicit
qualification should be preferred for unusual or infrequently used non-
local names. The increase of code clarity can be significant.

"On the other hand, explicit qualification of names that everybody knows
(or at least ought to know) and of frequently used names can become a
real nuisance. For example, writing stdio::printf, math::sqrt, and
iostream::cout is not going to help anyone acquainted with C++."

Now, as soon as I saw those smaller namespaces, I wondered: why not? Ten
pages later in D&E, in "17.4.5.5 Namespaces are Open", I read "Common
taste (including mine) favors the use of many smaller namespaces over
putting really major pieces of code into a single namespace."

So here's my question: Obviously someone (at least Stroustrup) thought of
more specialized namespaces than just a massive std. Were smaller
standard namespaces in a working version of the Standard at some point,
and then replaced with std before CD2? Or did this particular feature,
more specialized namespaces rather than a huge std, never make it into
any committee working papers?

I can see a big disadvantage to implementors of a huge std namespace.
Consider
 #include <math.h>     // A
 #include <cstdio>
versus
 #include <cstdio>     // B
 #include <math.h>
Since a common implementation of the xxxx.h headers is
 #include <cmath>      // Impl
 using namespace std;
(and Stroustrup even mentions it in D&E), the effect of at least A, and
possibly B as well, is to bring everything from <cstdio> into the global
namespace, even though the programmer specifically picked <cstdio> so as
not to do that.

In the standard at "[depr.c.headers] D.5 Standard C library headers"
(which if part of the normative Annex D), paragraph 2 says "Each C
header, whose name has the form name.h, behaves as if each name placed in
the Standard library namespace by the corresponding cname header is also
placed within the namespace scope of the name   space std and is followed
by an explicit using   declaration (7.3.3)". That seems pretty clear that
implementors can't just use "using namespace std;" as in Impl above
(though I wonder if any conform).

Are there any advantages to a big std namespace that I am missing? It
doesn't help old code, because old code has the <xxxx.h> headers anyway.
It doesn't help new code, because new code shouldn't be using the using-
directives anyway, and it's just as easy to type
 using stdio::printf;
as
 using std::printf;
(Well, just as easy give or take two characters.)

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/

"It's my opinion, and it's very true."
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

brahms@mindspring.com (Stan Brown) writes:

>I have a question about the evolution of namespaces after 1994, when D&E
>was published. Specifically, why is everything in the standard library in
>namespace std? ...

The question has at least three parts, which I'll discuss:
no namespace vs one namespace vs many smaller namespaces.

1. Why use namespaces for the standard library?

The C++ library contains a LOT of names, many of which could easily
collide with application program or OS-specific identifiers.  By
putting the C++ part of the library into a namespace (or possibly
several namespaces), we eliminate accidental name collision with
user programs and various other libraries.

2. If one namespace is good, wouldn't several be better?

What is best for project development is not necessarily best for
the language definition. You wouldn't want unrelated libraries
to use the same namespace -- it would lead to confusion and
name collisions.

But the C++ standard library is part of the language definition.
As far as the C++ standard is concerned, there is no real dichotomy
of language and library. An implementation can be very smart about
headers and library types and functions, and implement many of them
implicitly, just as (for example) sizeof is implicit. Having just
one namespace is therefore reasonable.

But would multiple namespaces be better? You would have to remember
where identifiers came from to use them. For many identifiers, the
appropriate namespace name would not be obvious.
 - The iostream capabilities are spread across different headers,
   with some duplication. Maybe just use "iostream::"?
 - Although most iostream functions are in iostream headers, header
   <string> has some. Confusing.
 - Many iterators are in header <iterator>, but some are in other
   headers. Confusing again.

On balance, it doesn't seem to be an advantage to split the
single C++ standard library into multiple namespaces.

3. Why is the part of the library inherited from C in the namespace?

A controversial topic. I'll try to present a balanced view of
the arguments on both sides.

Pro: The entire library is available in namespace std. You don't
have to remember which elements come from C and which are unique
to C++. You can always use the prefix "std::" -- except for macros,
which blunts this argument. In addition, the C part of the library
also contains a LOT of names, and we have the option of reducing
the name conflicts -- again, except for macros.

Con: "Everybody knows" the names that come from C -- except for
new programmers who start with C++ and don't learn C explicitly.
The macros can't be put into a namespace anyway. Implementation
is more difficult, where the C++ implementer doesn't own the C headers.

The C++ Committee voted overwhelmingly in favor of a single
namespace that included the C library in each of several votes
that were taken over the course of development of the standard.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.1257267a84574fee98a111@news.mindspring.com>, Stan Brown
<brahms@mindspring.com> writes
>Are there any advantages to a big std namespace that I am missing? It
>doesn't help old code, because old code has the <xxxx.h> headers anyway.
>It doesn't help new code, because new code shouldn't be using the using-
>directives anyway, and it's just as easy to type

Yes, one is that when working against the calendar (i.e. trying to
deliver in a timely fashion) putting them all in one namespace saved
many hours of debate and argument.  BTW, I note that you mentioned
various C-headers, remember that these are each free standing though
some things are declared in more than one header.  How do you decide
which specialised namespace they go in?



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> 3. Why is the part of the library inherited from C in the namespace?
>
> Pro: The entire library is available in namespace std. You don't
> have to remember which elements come from C and which are unique
> to C++. You can always use the prefix "std::" -- except for macros,
> which blunts this argument. In addition, the C part of the library
> also contains a LOT of names, and we have the option of reducing
> the name conflicts -- again, except for macros.

Another pro: There are borderline cases. Some functions from the C
library have been given slightly different behaviour in C++; for
example, the new signatures for some of the str...() functions, and the
extension of the maths functions to float and long double. If the "C
library" and "C++ library" were in separate namespaces, it's not obvious
which one these should go in.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  "There are many technical details that make Linux attractive to the
  sort of people to whom technical details are attractive."   -- Suck


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]