>
>But you can specialise the existing ones.

I think that you've hit the crux of the matter there - that seems to
be the one thing that really is guarenteed to fail in the scheme
suggested.

Since namespaces within std are reserved, one option would be to place
types defined by the standard in std as required, and implementation
classes (not defined by the standard) in std::implementation. That
should result in a "clean" implementation as far as clients of the
code are concerned, but requires a fair bit of extra typing for the
implementor :-)

John Maddock
http://ourworld.compuserve.com/homepages/John_Maddock/


[ 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              ]

James Kuyper Jr. <kuyper@wizard.net> schrieb in im Newsbeitrag:
3836254C.FD0E3C06@wizard.net...
> fbp@stlport.org wrote:

> It's currently perfectly legal for user code to define things in
> namespace std_impl; and such code is required to work just as it would
> if the implementation weren't using that namespace.

I' assume the OP's intent would be served by using namespace std::__impl,
but as others have ponted out that seems to be illegal as well.

--J   rg Barfurth




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

"James Kuyper Jr." wrote:
>
> fbp@stlport.org wrote:
> >
> > Hmm, I do not see how exactly another flavour of
> > include may help in this case. This is serious step
> > you have to do anyway : saying that the header might incude other does
> > not mean anything, you have to say it _must_ include it.
> > That will definitely be an overspecification.
> >
> > I think reasonable implementation may
> > ensure no extra names are defined at all:
> >
> > <iterator> : includes std_iterator.h
> >
> > std_iterator.h :  implements everything
> > <iterator> should implement, in namespace std_impl:: ;
> >
> > <iterator> : imports only those symbols standard
> > requires from std_impl:: into std:: ;
> >
> > With such a scheme in mind, nothing prevents
> > from stating that applications are not to expect any
> > other symbols defined in std:: except those explicitly
> > listed in the standard.
>
> It's currently perfectly legal for user code to define things in
> namespace std_impl; and such code is required to work just as it would
> if the implementation weren't using that namespace.

That's just nitpicking, though. Replace std_impl with __std_impl to put
the name in the implementor's namespace and this problem goes away.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

John Maddock wrote:
>
> Since namespaces within std are reserved, one option would be to place
> types defined by the standard in std as required, and implementation
> classes (not defined by the standard) in std::implementation. That
> should result in a "clean" implementation as far as clients of the
> code are concerned, but requires a fair bit of extra typing for the
> implementor :-)
>

The name of this internal namespace would still have to be of a form
that's reserved to the implementor, i.e. one that begins with an
underscore followed by a capital letter or with two underscores.
Otherwise using namespace std; could cause mysterious name clashes.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com

fbp@stlport.org wrote:
>
> Hmm, I do not see how exactly another flavour of
> include may help in this case. This is serious step
> you have to do anyway : saying that the header might incude other does
> not mean anything, you have to say it _must_ include it.
> That will definitely be an overspecification.
>
> I think reasonable implementation may
> ensure no extra names are defined at all:
>
> <iterator> : includes std_iterator.h
>
> std_iterator.h :  implements everything
> <iterator> should implement, in namespace std_impl:: ;
>
> <iterator> : imports only those symbols standard
> requires from std_impl:: into std:: ;
>
> With such a scheme in mind, nothing prevents
> from stating that applications are not to expect any
> other symbols defined in std:: except those explicitly
> listed in the standard.

It's currently perfectly legal for user code to define things in
namespace std_impl; and such code is required to work just as it would
if the implementation weren't using that namespace.
---
[ 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              ]

[Note to mods: fu2 set to ONE group]

Christopher Eltschka wrote:

> Matt Austern wrote:

> > That's a clever idea, but I don't think it's quite conforming.

Me too.

> But given that you are not allowed to define your own classes
> in namespace std,

But you can specialise the existing ones.

--

Valentin Bonnard
---
[ 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 wrote:
>
> fbp@stlport.org writes:
>
> > Hmm, I do not see how exactly another flavour of
> > include may help in this case. This is serious step
> > you have to do anyway : saying that the header might incude other does
> > not mean anything, you have to say it _must_ include it.
> > That will definitely be an overspecification.
> >
> > I think reasonable implementation may
> > ensure no extra names are defined at all:
> >
> > <iterator> : includes std_iterator.h
> >
> > std_iterator.h :  implements everything
> > <iterator> should implement, in namespace std_impl:: ;
> >
> > <iterator> : imports only those symbols standard
> > requires from std_impl:: into std:: ;
> >
> >
> > With such a scheme in mind, nothing prevents
> > from stating that applications are not to expect any
> > other symbols defined in std:: except those explicitly
> > listed in the standard.
>
> That's a clever idea, but I don't think it's quite conforming.  The
> standard, of course, says that library components are defined within
> namespace std (except for a few scraps in the global namespace and a
> few in std::rel_ops), and, becuase of Koenig lookup, defining a class
> in namespace std is visibly different from defining it in an
> implementation namespace and then importing it into namespace std.

But given that you are not allowed to define your own classes
in namespace std, and given that Koenig lookup only depends on
definitions being in the _same_ namespace, not on the name of
that namespace, I doubt that a conforming program could tell
the difference:

For example:

// std_complex.h

namespace __std // to avoid using a non-reserved name
{
  template<class T> class complex
  {
    // ...
  };

  template<class T>
   T real(complex<T> const& value);

  // ...
}

// complex

#ifndef _COMPLEX_H
#define _COMPLEX_H

#include <std_complex.h>

namespace std
{
  using __std::complex;
  using __std::real;
  // ...
}

// Some user program

#include <complex>

int main()
{
  std::complex<double> c(3.5, 4.1);

  double d1 = real(c);
      // selects __std::real through Koenig lookup

  double d2 = std::real(c);
     // selects std::real directly, which is __std::real through
     // the using declaration in <complex>
}

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

fbp@stlport.org writes:

> Hmm, I do not see how exactly another flavour of
> include may help in this case. This is serious step
> you have to do anyway : saying that the header might incude other does
> not mean anything, you have to say it _must_ include it.
> That will definitely be an overspecification.
>
> I think reasonable implementation may
> ensure no extra names are defined at all:
>
> <iterator> : includes std_iterator.h
>
> std_iterator.h :  implements everything
> <iterator> should implement, in namespace std_impl:: ;
>
> <iterator> : imports only those symbols standard
> requires from std_impl:: into std:: ;
>
>
> With such a scheme in mind, nothing prevents
> from stating that applications are not to expect any
> other symbols defined in std:: except those explicitly
> listed in the standard.

That's a clever idea, but I don't think it's quite conforming.  The
standard, of course, says that library components are defined within
namespace std (except for a few scraps in the global namespace and a
few in std::rel_ops), and, becuase of Koenig lookup, defining a class
in namespace std is visibly different from defining it in an
implementation namespace and then importing it into namespace std.
---
[ 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 <7vr7bf$5qi$1@mulga.cs.mu.OZ.AU>,
  fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
>
> This issue is actually a general problem with the language design
> that will potentially affect *every* C++ library, not just the
> standard library.

This is so true. I worked on such a project. We tried to use
the framework of one application (Parent/Child windows,
database routines, etc.) to write a new application, but we
found that if we #included one header, it required us to
#include another header, which required two others, and soon
we had almost the whole of the first application included!
It was painful, but over the next few months we managed to
completely redesign all of the include files. The short
version of the design methodology was: if ANY piece of code
(even in a header file) has a dependancy on a class A, then
that code must use a forward definition or else #include
ClassA.H, even if that code "knows" that ClassA.H should
have been #included from somewhere else (i.e. another
header file).

Unfortunately, breaking this rule cannot create a compiler
diagnostic. We did code reviews during the transition, but
there's no reason to believe that none of the revisions
made after that period broke the same rule.

> Bjarne's proposal for `include' instead of `#include'
> would have solved this.  Unfortunately it came too late.

Bjarne who?

Seriously, there must be more to the proposal than changing
    #include
to
    include
or else Bjarne wouldn't have proposed it. Was it a proposal
to include class/function/variable definitions which would
be local to the current source file, rather than #including
any legal C++ code which then would then have to apply to
the rest of the compilation unit? Please give us some of
the details. Understood that the proposal didn't make it,
but I think it would be interesting to read.

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

fbp@stlport.org wrote:

> <iterator> should implement, in namespace std_impl:: ;

The standard requires that names are defined in std,
not elsewhere.

--

Valentin Bonnard


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

Hmm, I do not see how exactly another flavour of
include may help in this case. This is serious step
you have to do anyway : saying that the header might incude other does
not mean anything, you have to say it _must_ include it.
That will definitely be an overspecification.

I think reasonable implementation may
ensure no extra names are defined at all:

<iterator> : includes std_iterator.h

std_iterator.h :  implements everything
<iterator> should implement, in namespace std_impl:: ;

<iterator> : imports only those symbols standard
requires from std_impl:: into std:: ;


With such a scheme in mind, nothing prevents
from stating that applications are not to expect any
other symbols defined in std:: except those explicitly
listed in the standard.

-Boris.

In article <7vr7bf$5qi$1@mulga.cs.mu.OZ.AU>,
  fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
> Matt Austern <austern@sgi.com> writes:
> >You're right, of course.  The committee knew that, and we knew that
it
> >would have been better if we could have specified exactly which names
> >each standard header was allowed to define.  Why didn't we do that?
> >The simple answer, I'm afraid, is that we didn't think we could.  The
> >issue arose late in the standardization process, and it would have
> >been a huge job.
>
> This issue is actually a general problem with the language design
> that will potentially affect *every* C++ library, not just the
> standard library.
>
> Bjarne's proposal for `include' instead of `#include' would have
solved
> this.  Unfortunately it came too late.
>
> --


Sent via Deja.com http://www.deja.com/
Before you buy.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

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

>smeyers@aristeia.com (Scott Meyers) writes:
>
>> It is my understanding that, unlike C, C++ says nothing about which
>> standard headers include other standard headers.  The more I think about
>> this, the more I think it's a portability problem.
>
>You're right, of course.  The committee knew that, and we knew that it
>would have been better if we could have specified exactly which names
>each standard header was allowed to define.  Why didn't we do that?
>The simple answer, I'm afraid, is that we didn't think we could.  The
>issue arose late in the standardization process, and it would have
>been a huge job.

This issue is actually a general problem with the language design
that will potentially affect *every* C++ library, not just the
standard library.

Bjarne's proposal for `include' instead of `#include' would have solved
this.  Unfortunately it came too late.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

>>>>> "Scott" == Scott Meyers <smeyers@aristeia.com> writes:

    Scott> It is my understanding that, unlike C, C++ says nothing
    Scott> about which standard headers include other standard
    Scott> headers.  The more I think about this, the more I think
    Scott> it's a portability problem.

As others point out, there is no guarantee that headers are implicitly
included.

A feature that I would like to see in C++ (and C) compilers is a
warning that a standard identifier has been used without including an
appropriate standard header.  Another feature would be to warn if an
included standard header is not used.

It may be possible to do such a thing in emacs, though it is unlikely
that parsing of the source code would match that done in a compiler.

One compiler that sort of does this is IBM's VisualAge.  You can omit
include statements altogether!  Of course the code is not not very
portable.
--
Pete Forman
Western Geophysical
pete.forman@westgeo.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              ]

smeyers@aristeia.com (Scott Meyers) writes:

> It is my understanding that, unlike C, C++ says nothing about which
> standard headers include other standard headers.  The more I think about
> this, the more I think it's a portability problem.

You're right, of course.  The committee knew that, and we knew that it
would have been better if we could have specified exactly which names
each standard header was allowed to define.  Why didn't we do that?
The simple answer, I'm afraid, is that we didn't think we could.  The
issue arose late in the standardization process, and it would have
been a huge job.

As an example of what this work would have involved: if you include
<iterator> it obviously has to declare the classes basic_streambuf<>,
basic_istream<>, and basic_ostream<>.  Unless we require those classes
to be present merely as forward declarations, that means that
implementors also have to declare, at a minimum, whatever is present
in their public and protected interfaces.  And that bare minimum isn't
a very useful list, since in practice you also need things for private
members, inline functions, and non-exported function templates.

The dependencies in the standard library are complicated, and they
come very close to circularity.  I don't think anybody is prepared to
write down a minimal set of dependencies (or to defend any non-minimal
set as the one that all implementors should be required to support)
for any but the simplest of the standard headers.

My advice to users: include every standard header that the standard
says you need.  You might find that you can omit some on your current
compiler, but you shouldn't assume that the same omissions will work
anywhere else.
---
[ 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              ]

It is my understanding that, unlike C, C++ says nothing about which
standard headers include other standard headers.  The more I think about
this, the more I think it's a portability problem.  For example, consider
this program, which just copies strings from cin to cout:

  #include <vector>
  #include <iostream>
  #include <iterator>
  #include <string>

  int main()
  {
    using namespace std;

    istream_iterator<string> input(cin), eof;
    vector<string> v(input, eof);
    copy(v.begin(), v.end(), ostream_iterator<string>(cout, "\n"));

    return 0;
  }

I felt like quite the manly programmer when this compiled an ran as
expected (my standards in the manliness category are fairly low...), but
then I noticed that the C++ standard says that the "copy" algorithm is
declared in <algorithm>, which my program above fails to include.  Ignoring
any other problems the program above may have, does the standard guarantee
that "copy" is visible in main at the point where I call it, or might other
implementations insist that I first include <algorithm>?

Thanks,

Scott

--
Scott Meyers, Ph.D.                  smeyers@aristeia.com
Software Development Consultant      http://www.aristeia.com/
Visit http://meyerscd.awl.com/ to demo the Effective C++ CD

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

Scott Meyers <smeyers@aristeia.com> wrote:

> It is my understanding that, unlike C, C++ says nothing about which
> standard headers include other standard headers.  The more I think about
> this, the more I think it's a portability problem.

Agreed.

> [...] does the standard guarantee
> that "copy" is visible in main at the point where I call it, or might other
> implementations insist that I first include <algorithm>?

An implementation is allowed to insist that you first include <algorithm>.

    -- Darin
---
[ 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              ]

On 30 Oct 99 01:06:25 GMT, smeyers@aristeia.com (Scott Meyers) wrote:
>It is my understanding that, unlike C, C++ says nothing about which
>standard headers include other standard headers.

Correct.

>The more I think about this, the more I think it's a portability problem.

Yes, but I think there are more compelling reasons.

In the case you describe (a program that happens to work even though the
programmer forgot to #include a header, because the implementation
happened to #include it indirectly via another standard header) I don't
think is really a portability problem per se, because any conforming
program will #include the right headers and therefore will not be
susceptible to the problem you describe. I agree that it's a pain for
someone who missed a header on an implementation where it didn't happen
to matter and is therefore unwittingly defining on a little bit of
implementation-defined behavior, and then ports that code to an
implementation where it does matter, but you already get that effect for
any number of reasons anytime you rely on implementation-defined
behavior, right?

Now consider the example I analyzed in the March 1999 issue of C++
Report. The code is:

  // Example 1: Will this compile?
  //
  // in some library header
  namespace N { class C {}; }
  int operator+(int i, N::C) { return i+1; }

  // a mainline to exercise it
  #include <numeric>
  int main() {
    N::C a[10];
    std::accumulate(a, a+10, 0);
  }

The answer to "will this compile?" is: Maybe. The above code is NOT
portable, even though it may look portable. I know of conforming
implementations where it will, and conforming implementations where it
won't. The issue is that, during name lookup, header <numeric> might
indirectly pull in another standard header that happens to define an
operator+(), in which case the example will not compile (see my cited
column for a longer discussion of why this is and how this interferes
with name lookup) -- or it might not, in which case the example will
compile.

In fact, the compiler diagnostic messages you get can be singularly
unhelpful. On my platform, compiling the above code generates the
following messages:

error C2784: 'class
std::reverse_iterator<`template-parameter-1',`template-parameter-2',`template-parameter-3',`template-parameter-4',`template-parameter-5'>
__cdecl std::operator +(template-parameter-5,const class
std::reverse_iterator<`template-parameter-1',`template-parameter-2',`template-parameter-3',`template-parameter-4',`template-parameter-5'>&)'
: could not deduce template argument for 'template-parameter-5' from
'int'

error C2677: binary '+' : no global operator defined which takes type
'class N::C' (or there is no acceptable conversion)

What the heck is reverse_iterator doing in there? Well, guess what
<numeric> indirectly included... :-> Pity the poor programmer who has to
figure out what's going wrong here. (Short answer: Always define
operators in the same namespace as the types they manipulate -- if
possible, because what about operators manipulating two types from
different namespaces?)

>does the standard guarantee
>that "copy" is visible in main at the point where I call it, or might other
>implementations insist that I first include <algorithm>?

Clause 25, Table 1, states that mutating sequence operations (of which
std::copy() is one) appear in header <algorithm>; the immediately
following synopsis of header <algorithm> then specifically declares
std::copy().  Thus the only portable way to use std::copy() is after an
#include <algorithm>, although some implementations may happen to make
your above example work if some other header #includes <algorithm> (or
#includes another internal common header where copy() actually resides
and that is also in turn #include'd by <algorithm>).

On my system, #include'ing any of complex, list, vector, deque, stack,
map, set, or ANY stream-related stuff, will get you copy() as well (but
not necessarily the rest of the stuff in <algorithm>).

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

PeerDirect Inc.     2695 North Sheridan Way, Suite 150
www.peerdirect.com  Mississauga Ontario Canada L5K 2N6
---
[ 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              ]