Ajay Kamdar wrote:

> Compatibility could have been provided by making ostream a class
> instead of a typedef. i.e.,
>
> class ostream : public basic_ostream<char> {
>  ...
> };
>
> The body of the ostream class would be pretty small, and consist
> of only a small number of functions which forward the calls to
> basic_ostream<char>. Were there problems percieved with this simple
> solution which could help maintain compatibility with existing code
> base?

Not a bad idea, IMHO.  Is the linker required to
have access to copies of all member functions in
this case?  It would be nice if there was a way to
prevent having to include as many HUGE headers ...

just my basic_string header is tremendous.

--
#include <legalbs/standarddisclaimer>
Rich Paul                |  If you like what I say,
tell my
C++, OOD, OOA, OOP,      |  employer, but if you
don't,
OOPs, I forgot one ...   |  don't blame them.  ;->
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage wrote:

> No, that can't be made to work.
>
> You will have to modify existing code to include the new standard
> header <iosfwd> instead of forward declarations like
>         class ostream;
> The <iosfwd> header contains a set of declarations including
>         typedef basic_ostream<char> ostream;
>

It certianly would be nice, though, especially in light of the stl.
I am currently using:

 // OneHeader.h
 class Object;
 class ObjectList;

 class Some_Class_Using_Object_And_Or_ObjectList {
 }

 // OtherHeader.h
 class Object {
 };

 class ObjectList : public list<Object> { // this annoies me
 };

The only problem is rewriting the constructors ...

--
#include <legalbs/standarddisclaimer>
Rich Paul                |  If you like what I say, tell my
C++, OOD, OOA, OOP,      |  employer, but if you don't,
OOPs, I forgot one ...   |  don't blame them.  ;->
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4m59bo$mv2@engnews1.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>ajay@lehman.com (Ajay Kamdar) writes:
>
>>Given that the standardization committee has gone to considerable
>>lengths to maintain compatibility with C, I believe it is safe to
>>presume that equal, if not more, consideration has been given to
>>maintaining compatibility with the existing body of legal C++ code.
>
>>It would be instructive to know whether the following legal C++
>>code fragment will continue to be legal without any modifications,
>>and understand how the standard arranges for it to be legal.
>
>
>>  foo.h
>>  -----
>>  class ostream;      // fwd decl
>
>>  struct foo {
>>      void g(ostream&);
>>  };
>
>No, that can't be made to work.
>
>You will have to modify existing code to include the new standard
>header <iosfwd> instead of forward declarations like
> class ostream;
>The <iosfwd> header contains a set of declarations including
> typedef basic_ostream<char> ostream;
>

Was this a conscious decision (to require existing code using iostreams
to change) or something that just slipped by? Given the committee's
track record on bending backwards to accomodate even obtuse uses of
the language, I find it very surprising that a conscious decision to
make illegal perfectly legal and _good_ code like the one shown above
would be made without some very strong reasons. There are possibly
thousands, if not hundreds of thousands, of header files that
would need to be changed to accomodate the new iostreams. A lot
of it could possible be automated, but the sheer size of the
affected code still makes it an undesirable course of action.


Compatibility could have been provided by making ostream a class
instead of a typedef. i.e.,

class ostream : public basic_ostream<char> {
 ...
};

The body of the ostream class would be pretty small, and consist
of only a small number of functions which forward the calls to
basic_ostream<char>. Were there problems percieved with this simple
solution which could help maintain compatibility with existing code
base?
--
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer
Lehman Brothers    |    Phone: (201) 524-5048     |
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Ajay Kamdar (ajay@lehman.com) wrote:
: Given that the standardization committee has gone to considerable
: lengths to maintain compatibility with C, I believe it is safe to
: presume that equal, if not more, consideration has been given to
: maintaining compatibility with the existing body of legal C++ code.

I don't believe your assumption is valid, for two reasons:

 * I have observed considerably less concern about changing aspects
   of the draft specifications for C++ than has been given to
   preserving the validity of ISO C code; and
 * since there is no standard for C++ yet, it would be difficult
   to come up with a universally agreed definition for the word
   "legal" with respect to C++.

In fact I believe that the lack of stability in the draft standard
until relatively recently has been a significant barrier to more
widespread adoption of C++ features (I know it's made me pretty
cautious).

Bob Kline


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Given that the standardization committee has gone to considerable
lengths to maintain compatibility with C, I believe it is safe to
presume that equal, if not more, consideration has been given to
maintaining compatibility with the existing body of legal C++ code.

It would be instructive to know whether the following legal C++
code fragment will continue to be legal without any modifications,
and understand how the standard arranges for it to be legal.


  foo.h
  -----
  class ostream;      // fwd decl

  struct foo {
      void g(ostream&);
  };

  foo.cpp
  -------
  #include "foo.h"
  #include <iostream.h>

  void foo::g(ostream& os) { /*...*/ }


Here foo.h forward declares the class ostream rather than including
iostream.h (which is a pretty common idiom, and the advantages of using
this idiom with iostreams are especially significant). iostream.h is
included by foo.cpp to implement g().


Unless something else has changed in the language, the following
sequence of C++ statements is currently illegal and will not compile:

  class   A;
  struct  B {};
  typedef B A;     // error. multiple declaration of A


Because, in the DWP, ostream is actually a typedef for
basic_ostream<char>, this is exactly the pattern that would occur
when compiling the above currently legal C++ code using the new
definition of ostream. Hence it would seem that this legal C++
code will fail to compile with the new iostreams library. Is
that observation correct? Will all programs forward declaring iostreams
need to be modified to include <iostream> or <iosfwd>? Otherwise
how will this code work unchanged with the new iostreams library?

On a related note, because string is also a typedef for
basic_string<char> in the DWP, it looks like it will be impossible
to forward declare class string and that instead <string> will always
have to be included. Manually forward declaring the basic_string
template, then forward declaring basic_string<char> would be a very
unappealing alternative to a simple "class string;". Which raises
another question: why is there no <strfwd> for <string> similar to
<iosfwd> for <iostream>?

--
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer
Lehman Brothers    |    Phone: (201) 524-5048     |
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

ajay@lehman.com (Ajay Kamdar) writes:

>Given that the standardization committee has gone to considerable
>lengths to maintain compatibility with C, I believe it is safe to
>presume that equal, if not more, consideration has been given to
>maintaining compatibility with the existing body of legal C++ code.

>It would be instructive to know whether the following legal C++
>code fragment will continue to be legal without any modifications,
>and understand how the standard arranges for it to be legal.


>  foo.h
>  -----
>  class ostream;      // fwd decl

>  struct foo {
>      void g(ostream&);
>  };

No, that can't be made to work.

You will have to modify existing code to include the new standard
header <iosfwd> instead of forward declarations like
 class ostream;
The <iosfwd> header contains a set of declarations including
 typedef basic_ostream<char> ostream;

--
Steve Clamage, stephen.clamage@eng.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]