In article <rfgCHCnr0.9FC@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
   In article <15882@anderson> anderson@Software.Mitel.COM (David Anderson) writes:
   >I just read someone's post in comp.lang.c++ that said the ANSI C++ standard
   >committee is removing the multiple inheritance implementation of the IO Stream
   >library.

   Lemme make two points.

   First, why should you care how C++ I/O streams are implemented?  Are you an
   implementor, or just an end-user of compilers & libraries?  If the latter,
   then you shouldn't care how the library is implemented.  The interface should
   be the only thing that matters to you.

Ah... but in this case the multiple inheritance is part of the interface:
there are a whole bunch of public keywords in the current iostream
class declarations.

   Second, I kinda hope that the C++ standardization committee is *not* trying
   to specify how library classes are to be implemented. I think that would go
   way beyond their charter.

If classes are to be standardized it would seem to be a good idea to
include their public inheritance hierarchies in the standard.

 Chris Flatters
 cflatter@nrao.edu

In article <JAK.93Dec1102644@aruba.cs.brown.edu> jak@cs.brown.edu writes:
>>>>>> On Wed, 1 Dec 1993 09:30:35 GMT, rfg@netcom.com (Ronald F. Guilmette) said:
>
> rfg> In article <15882@anderson> anderson@Software.Mitel.COM (David Anderson) writes:
>
> rfg> Lemme make two points.
>
> rfg> First, why should you care how C++ I/O streams are implemented?
> rfg> Are you an implementor, or just an end-user of compilers &
> rfg> libraries?  If the latter, then you shouldn't care how the library
> rfg> is implemented.  The interface should be the only thing that
> rfg> matters to you.
>
> rfg> Second, I kinda hope that the C++ standardization committee is
> rfg> *not* trying to specify how library classes are to be
> rfg> implemented. I think that would go way beyond their charter.
>
>The implementation of the iostream library *does* affect end-users of
>the libraries insofar as they wish to define their own types of streams.
>As someone who has occasionally been asked in C++ courses to teach
>people how to do this, I would very much appreciate a specification of
>the implementation *as it affects derived types of streams*.

I think you are confusing implementation with interface (and vise versa).

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

rfg = rfg@netcom.com (Ronald F. Guilmette)
jak = jak@cs.brown.edu (Jak Kirman)

da> I just read someone's post in comp.lang.c++ that
da> said the ANSI C++ standard committee is removing the multiple
da> inheritance implementation of the IO Stream library.

rfg> First, why should you care how C++ I/O streams are implemented?
rfg> Are you an implementor, or just an end-user of compilers &
rfg> libraries?  If the latter, then you shouldn't care how the library
rfg> is implemented.  The interface should be the only thing that
rfg> matters to you.

rfg> Second, I kinda hope that the C++ standardization committee is
rfg> *not* trying to specify how library classes are to be
rfg> implemented. I think that would go way beyond their charter.

 jak> The implementation of the iostream library *does* affect end-users
 jak> of the libraries insofar as they wish to define their own types of
 jak> streams.  As someone who has occasionally been asked in C++
 jak> courses to teach people how to do this, I would very much
 jak> appreciate a specification of the implementation *as it affects
 jak> derived types of streams*.

  rfg> I think you are confusing implementation with interface (and vise
  rfg> versa).

I will readily concede that I was using the term implementation
inaccurately, and that in fact the visible portion of the inheritance
hierarchy of a library is part of its interface.

However, this is completely irrelevant; the original question was
whether the standardization committee is going to specify the visible
portion of the inheritance hierarchy of the iostream library to use
single inheritance, rather than the multiple inheritance commonly in
use.  The question was phrased differently, using the term
"implementation", which caused the confusion.  Your response was "you
shouldn't care", and I was pointing out that we certainly do care.

Can someone provide a more constructive answer to the original question?

                         Jak Kirman                        jak@cs.brown.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Experience is the name everyone gives to their mistakes.
                                                              -- Oscar Wilde

jak> The implementation of the iostream library *does* affect end-users of
jak> the libraries insofar as they wish to define their own types of streams.
jak> As someone who has occasionally been asked in C++ courses to teach
jak> people how to do this, I would very much appreciate a specification of
jak> the implementation *as it affects derived types of streams*.  Of course
jak> I don't think the implementation of individual classes in the iostream
jak> library should be specified, nor do I need to know (except perhaps to
jak> help me define my own streams) how current implementations work.

I suppose we can quibble over what's implementation and what's specification.
As far as I'm concerned anything that affects the ability
to derive from a class is specification.  The standard will certainly
contain enough information to allow deriving from istream and ostream.

On the other hand, my experience is that most people who start out
thinking they want to derive from istream or ostream really want to
derive a new streambuf.

And to answer the question that started this thread: The current
working paper does not contain the "two way" classes iostream, fstream, ...
However, the derivation of istream and ostream from ios is required
to be virtual, which allows a user to derive their own two way
classes if they desire it.

  -- Jerry Schwarz (jss@lucid.com)

In article <rfgCHCnr0.9FC@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <15882@anderson> anderson@Software.Mitel.COM (David Anderson) writes:
>>Hello:
>>
>>I just read someone's post in comp.lang.c++ that said the ANSI C++ standard
>>committee is removing the multiple inheritance implementation of the IO Stream
>>library.
>>
>>Is there any truth to this?
>
>Lemme make two points.
>
>First, why should you care how C++ I/O streams are implemented?  Are you an
>implementor, or just an end-user of compilers & libraries?  If the latter,
>then you shouldn't care how the library is implemented.  The interface should
>be the only thing that matters to you.
>
>Second, I kinda hope that the C++ standardization committee is *not* trying
>to specify how library classes are to be implemented. I think that would go
>way beyond their charter.

 Unfortunately, C++ does not support the type of high level
abstraction that allows full separation of type specification
and implementation details.

 Therefore, implementation details and interface specifications
are often inextricably intertwined. In some cases these things
are efficiency issues. For example, originally the proposed ISO
string class did not support

 char string::operator[](int)const;
 char& string::operator[](int);

(it does now)
because the C++ language design fails to select the correct function
in the case:

 string s;
 char c = s[20]; // selects non-const version: wrong one

and while this works it causes unnessary splitting of shared
representations (reference counted strings). Similarly, this
use is unsafe (dangling reference is possible).

 The problem is that C++ is not a purpose designed object
oriented language. In fact, its a langauge beset by problems which
stem from its C heritage: to give the programmer direct control
over the machine.

 As I think any class designer will tell you, abstract
design is basically a fairy tale. Implementation details rapidly
become significant in class library designs.

 While it is true the *standard* library has advantages
over user defined ones -- its basically a language extension
specified in terms of the core language -- the library must
still be specified in a way such that actual implementations
look like a user defined library.

 Thats a heavy constraint. The committee just adopted
a new data type -- bool -- as part of the core language.
It was not felt a library entity could be made to operate in
the desired way.





--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

jss@lucid.com (Jerry Schwarz) writes:

>jak> The implementation of the iostream library *does* affect end-users of
>jak> the libraries insofar as they wish to define their own types of streams.
>jak> As someone who has occasionally been asked in C++ courses to teach
>jak> people how to do this, I would very much appreciate a specification of
>jak> the implementation *as it affects derived types of streams*.  Of course
>jak> I don't think the implementation of individual classes in the iostream
>jak> library should be specified, nor do I need to know (except perhaps to
>jak> help me define my own streams) how current implementations work.

>I suppose we can quibble over what's implementation and what's specification.
>As far as I'm concerned anything that affects the ability
>to derive from a class is specification.  The standard will certainly
>contain enough information to allow deriving from istream and ostream.

>On the other hand, my experience is that most people who start out
>thinking they want to derive from istream or ostream really want to
>derive a new streambuf.

>And to answer the question that started this thread: The current
>working paper does not contain the "two way" classes iostream, fstream, ...
>However, the derivation of istream and ostream from ios is required
>to be virtual, which allows a user to derive their own two way
>classes if they desire it.

Isn't the committee going to break a lot of code if they remove iostream and
fstream from the iostream hierarchy?  Every compiler manufacturer will have
to put this into the heirarchy, to support working code.  Those people who
are trying to compile as strictly ANSI, will have to do some serious
re-writes! This doesn't make sense to me!

--
Rick Stanley                         |              RSI
stanleyr@acf4.nyu.edu                |         (212) 569-9304
Information Technologies Institute   |        C++ & C Language
New York University   NYC, NY  USA   | Programming, Training, Consulting

Hello:

I just read someone's post in comp.lang.c++ that said the ANSI C++ standard
committee is removing the multiple inheritance implementation of the IO Stream
library.

Is there any truth to this?

On another note...

I noticed how the ARM doesn't discuss the IOstream library :-(

I would like to know what base the ANSI standard committee are using for the
IO stream library.

Why?

I am putting a C++ course together and I would like to know what to include
about the IO Stream library. I would like to give some insight on the
standardization efforts...

Any pointers or references ( no pun intended :-)

Regards,

/David
--
--------------------------------------------------
David AR Anderson   Email: anderson@Software.Mitel.COM
Integration Management
Mitel Corporation   Disclaimer: My opinions are my own!

In article <15882@anderson> anderson@Software.Mitel.COM (David Anderson) writes:
>Hello:
>
>I just read someone's post in comp.lang.c++ that said the ANSI C++ standard
>committee is removing the multiple inheritance implementation of the IO Stream
>library.
>
>Is there any truth to this?

Lemme make two points.

First, why should you care how C++ I/O streams are implemented?  Are you an
implementor, or just an end-user of compilers & libraries?  If the latter,
then you shouldn't care how the library is implemented.  The interface should
be the only thing that matters to you.

Second, I kinda hope that the C++ standardization committee is *not* trying
to specify how library classes are to be implemented. I think that would go
way beyond their charter.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

>>>>> On Wed, 1 Dec 1993 09:30:35 GMT, rfg@netcom.com (Ronald F. Guilmette) said:

 rfg> In article <15882@anderson> anderson@Software.Mitel.COM (David Anderson) writes:

 rfg> Lemme make two points.

 rfg> First, why should you care how C++ I/O streams are implemented?
 rfg> Are you an implementor, or just an end-user of compilers &
 rfg> libraries?  If the latter, then you shouldn't care how the library
 rfg> is implemented.  The interface should be the only thing that
 rfg> matters to you.

 rfg> Second, I kinda hope that the C++ standardization committee is
 rfg> *not* trying to specify how library classes are to be
 rfg> implemented. I think that would go way beyond their charter.

The implementation of the iostream library *does* affect end-users of
the libraries insofar as they wish to define their own types of streams.
As someone who has occasionally been asked in C++ courses to teach
people how to do this, I would very much appreciate a specification of
the implementation *as it affects derived types of streams*.  Of course
I don't think the implementation of individual classes in the iostream
library should be specified, nor do I need to know (except perhaps to
help me define my own streams) how current implementations work.

                         Jak Kirman                        jak@cs.brown.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ya gotta feel sorry for all them convicts in New Hampshire, stampin'
out license plates that say "Live free or Die."