In article <3oqlrr$bsa@engnews2.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>In article GA5@lcpd2.SanDiegoCA.ATTGIS.COM, swf@elsegundoca.ncr.com (Stan Friesen) writes:
>>
>>Is the standard written in such a way that fstream is an allowable *extension*
>>of the library?  That is, can implementations that have it keep it as is
>>[including keeping it in the same header]?
>
>I believe that an implementation can add fstream, since it would be in the
>"std" namespace, and so cannot conflict with user programs. (Programmers
>cannot add to that namespace.)

 That is NOT technically correct. Programmers CAN add to the
std namespace, and in fact they cannot use a single template from
it without adding too it. Every "instance" or specialisation of
a template from namespace X has to be a member of namespace X --
even if "X" is "std".

 Suppose you want to specialise vector<MyType>.
You MUST write:

 namespace std {
  class vector<MyType> { .... };
 }

To avoid adding a friend global to std requires code like this:

 namespace user {
  class MyType { ..};
  bool operator ==(vector<MyType> const&, ..);
 }
 namespace std {
  class vector<MyType> { ...
   friend bool user::operator==(vector<My.....)
  ..
 };
 namespace user {
  bool operator == ( .. ) { ..... }
 }

you have to first declare the global in user, then switch to
std to define the class and declare the function as a friend,
then switch back to user to defined the function.

It may be possible to relax the rules so that specialisations
of templates can be defined in a namespace OTHER than the
namespace in which the template is defined, but an explicit
rule is required permitting this exception, such a rule
doesn't exist at present AFAIK.

Note that while you CAN write:

 class X { void f(); }
 void X::f() { .. }

you cannot do the same thing for namespaces:

 namespace X { void f(); }
 void X::f() { .. } // ERROR-- not permitted

And a template specialisation is a definition of an entity
which exists in the namespace of the original template.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

>(There was a failed attempt to make iostreams more efficient by removing
>multiple inheritance and thus the need for virtual base classes. It turned
>out there wasn't a good way to create a bidirectional stream in that case,
>so ios was restored to being a virtual base class. That in turn makes it
>possible to restore fstream.)

Couldn't something like

class fstream
{
  ifstream ifs;
  ofstream ofs;
public:

//...
  template<class T> ostream& operator<<(T arg) {return ofs<<arg;}
  template<class T> istream& operator>>(T arg) {return ifs>>arg;}
//...
}

be a solution?

In article 1bse@ftp.univie.ac.at, am@beta.mdy.univie.ac.at (Alfred Minarik) writes:
>>(There was a failed attempt to make iostreams more efficient by removing
>>multiple inheritance and thus the need for virtual base classes. It turned
>>out there wasn't a good way to create a bidirectional stream in that case,
>>so ios was restored to being a virtual base class. That in turn makes it
>>possible to restore fstream.)
>
>Couldn't something like
>
>class fstream
>{
>  ifstream ifs;
>  ofstream ofs;
>public:
>
>//...
>  template<class T> ostream& operator<<(T arg) {return ofs<<arg;}
>  template<class T> istream& operator>>(T arg) {return ifs>>arg;}
>//...
>}
>
>be a solution?

The problem is that class ios contains stream state information. You
would have to find some way to synchronize the state information in
the two stream classes. The only practical way I know is for the
two streams to share the same ios base class instance. That in turn
means making ios a virtual base class and having fstream inherit from both
ifstream and ofstream. That is, a scheme like the original iostreams.

For some purposes it might be suitable to attach an ifstream and an
ofstream to the same file and have them share the same filebuf, but
that probably is not the general solution.

I don't claim that no better solution exists, but that no one on
the C++ Committee has found or been shown a workable alternative design.
---
Steve Clamage, stephen.clamage@eng.sun.com

In article <3otc9h$474@engnews2.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>The problem is that class ios contains stream state information. You
>would have to find some way to synchronize the state information in
>the two stream classes. The only practical way I know is for the
>two streams to share the same ios base class instance. That in turn
>means making ios a virtual base class and having fstream inherit from both
>ifstream and ofstream. That is, a scheme like the original iostreams.

My iostream implementation as released in versions of libg++ prior
to version 2.3 did not use multiple inheritance.  Instead it did:

 class istream : public ios {
    ... istream methods ...;
 };
 class ostream : public ios {
    ... ostream methods ...;

 };
 class iostream : public ios {
   public:
     operator istream&() { return *(istream*)this; }
     operator ostream&() { return *(ostream*)this; }
    ... istream methods (duplicated) ...;
    ... ostream methods (duplicated) ...;
 };
 class ifstream : public istream { ... }
 class ofstream : public ostream { ... }
 class fstream : public iostream { ... }

This worked well, for most programs.  However, a few programs
and libraries (notably Rogue Wave) depended on virtual
inheritance, so in August 1992 I decided that compatibility was
more important than efficiency, and re-wrote it to use virtual
and multiple inheritance, like everyone else.  Alas.

>I don't claim that no better solution exists, but that no one on
>the C++ Committee has found or been shown a workable alternative design.

Jerry Schwarz knew of my implementation.

Of course by now the committee has forced bigger and more incompatible
changes than using my class structure would have caused ...
--
 --Per Bothner
Cygnus Support     bothner@cygnus.com

In article <1995May4.204513.15166@nlm.nih.gov>, bkline%occs.nlm.nih.gov (Bob Kline Phoenix Contract) writes:
|>
|> Ah, Steve, I only wish you were right.  Unfortunately, however, I'm
|> afraid fstream has been the target of the committee's disfavor for
|> some time now.

A side question:

Is the standard written in such a way that fstream is an allowable *extension*
of the library?  That is, can implementations that have it keep it as is
[including keeping it in the same header]?

--
swf@elsegundoca.attgis.com  sarima@netcom.com

The peace of God be with you.

In article GA5@lcpd2.SanDiegoCA.ATTGIS.COM, swf@elsegundoca.ncr.com (Stan Friesen) writes:
>
>Is the standard written in such a way that fstream is an allowable *extension*
>of the library?  That is, can implementations that have it keep it as is
>[including keeping it in the same header]?

I believe that an implementation can add fstream, since it would be in the
"std" namespace, and so cannot conflict with user programs. (Programmers
cannot add to that namespace.) I expect implementations to continue to
support fstream.

With sufficient public support, fstream could be added back to the standard.

(There was a failed attempt to make iostreams more efficient by removing
multiple inheritance and thus the need for virtual base classes. It turned
out there wasn't a good way to create a bidirectional stream in that case,
so ios was restored to being a virtual base class. That in turn makes it
possible to restore fstream.)
---
Steve Clamage, stephen.clamage@eng.sun.com

Kalyan Kolachala (kal@chromatic.com) wrote:
: ray@cse.ucsc.edu (Ray Swartz) wrote:
: >Borland 4.5 C++ compiler has fstream types.  The draft
: standard
: >I have (from 1/94, unfortunately) has fstream.h but doens't
: >show any fstream in it.
: >
: >Is it correct ANSI usage to use fstream?
: >
: >Ray Swartz
: >
:
: Unfortunately that's true. The class fstream has been
: removed from the I/O streams. The reason seems to be to
: avoid having Multiple inheritance in the standard library
: and that the functionality of the bidirectional streams can
: be obtained easily.
:
: Currently one can obtain the functionality of fstream classes
: as follows:
:
: previously: fstream f("file");
:
: now: filebuf fb ("file");
:      istream is (&fb);
:      ostream os (&fb);
:

Unless you have access to more recent information than I have (I'm
looking at the draft of 28 April 1995) there is no filebuf constructor
which takes the filename and opens the file for you.  I believe you'll
need another line with a call to filebuf::open(), which only adds
weight to your comment that the removal of the bidirectional fstream
class was indeed unfortunate.

: or
:       ifstream ifs("file", ios::in | ios::out);
:       ostream  (ifs.rdbuf());
:
: This however requires a knowledge of the buffer classes,
: hitherto unnecessary for simple uses as above and management
: of two stream objects to work with one file.
:

The fact that you left out the variable name in your second example
is just a trivial mistake, I know, but I've seen it more than once,
probably because it seems unnatural to have to create two variables
to manipulate a single object in situations where the original
version of the library only needed one.  I know it's unlikely at
this late date, but this is one issue which I seriously hope the
committee will reconsider.  It does seem silly for the designers
of a language to say "here's a wonderful and useful feature [MI]"
in one breath and in the next claim that it's too tricky to use
in the standard libraries for that language.

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@csof.com                 formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 4uf@darkstar.UCSC.EDU, ray@cse.ucsc.edu (Ray Swartz) writes:
: >Borland 4.5 C++ compiler has fstream types.  The draft standard
: >I have (from 1/94, unfortunately) has fstream.h but doens't
: >show any fstream in it.

: Class fstream, a file stream which allows both input and output, has
: always been part of C++ iostreams. If the draft of 1/94 didn't include
: it, that was an error.

Ah, Steve, I only wish you were right.  Unfortunately, however, I'm
afraid fstream has been the target of the committee's disfavor for
some time now.  I'm told they don't feel MI is sufficiently ready
for prime time to show up in the standard libraries.  If you have
some pull with committee members in strategic places, though, perhaps
you can convince them otherwise! :->}

--
/*----------------------------------------------------------------------*/
/* Bob Kline                                       Stream International */
/* bob_kline@csof.com                 formerly Corporate Software, Inc. */
/* voice: (703) 522-0820 x-311                      fax: (703) 522-5407 */
/*----------------------------------------------------------------------*/

ray@cse.ucsc.edu (Ray Swartz) wrote:
>Borland 4.5 C++ compiler has fstream types.  The draft
standard
>I have (from 1/94, unfortunately) has fstream.h but doens't
>show any fstream in it.
>
>Is it correct ANSI usage to use fstream?
>
>Ray Swartz
>

Unfortunately that's true. The class fstream has been
removed from the I/O streams. The reason seems to be to
avoid having Multiple inheritance in the standard library
and that the functionality of the bidirectional streams can
be obtained easily.

Currently one can obtain the functionality of fstream classes
as follows:

previously: fstream f("file");

now: filebuf fb ("file");
     istream is (&fb);
     ostream os (&fb);

or
      ifstream ifs("file", ios::in | ios::out);
      ostream  (ifs.rdbuf());

This however requires a knowledge of the buffer classes,
hitherto unnecessary for simple uses as above and management
of two stream objects to work with one file.

- Kalyan

clamage@Eng.Sun.COM (Steve Clamage) wrote:
>In article 4uf@darkstar.UCSC.EDU, ray@cse.ucsc.edu (Ray
Swartz) writes:
>>Borland 4.5 C++ compiler has fstream types.  The draft
standard
>>I have (from 1/94, unfortunately) has fstream.h but doens't
>>show any fstream in it.
>
>Class fstream, a file stream which allows both input and
output, has
>always been part of C++ iostreams. If the draft of 1/94 didn't
include
>it, that was an error.
>
>BTW, don't try to use anything older than the public-comment
version of the
>draft for questions about the C++ library. The library section
has been very
>volatile and undergone many rewrites.  Changes from now on
should be relatively
>minor. (The public-comment version of the draft will be
available for ftp soon.)
>---
>Steve Clamage, stephen.clamage@eng.sun.com
>
>

As far as I know none of the bidirectional stream classes have
been part of the iostreams in the standard library. There was
a proposal by Jerry Schwarz at Valley Forge to include these
classes but that (to the best of my knowledge) wasn't accepted.

Strangely enough not many people seem to be aware of this
fact. To obtain the behavior of the bidirectional classes
(eg fstream) one has to explicitly create a filebuf object
and construct istream and ostream objects from the filebuf
object. Thus to manipulate a file one has to work with two
stream objects. This is indeed unfortunate, IMHO.

- Kalyan

Just a simple add-on question. Have the classes ifstream and ofstream
gone, as well?

Thanks for any replies.
Helmut Jarausch
Institute of Technology
RWTH Aachen
Germany

In article m9@news.rwth-aachen.de, jarausch@igpm.rwth-aachen.de (Helmut Jarausch) writes:
>Just a simple add-on question. Have the classes ifstream and ofstream
>gone, as well?

No, they are still there.

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

Borland 4.5 C++ compiler has fstream types.  The draft standard
I have (from 1/94, unfortunately) has fstream.h but doens't
show any fstream in it.

Is it correct ANSI usage to use fstream?

Ray Swartz

In article 4uf@darkstar.UCSC.EDU, ray@cse.ucsc.edu (Ray Swartz) writes:
>Borland 4.5 C++ compiler has fstream types.  The draft standard
>I have (from 1/94, unfortunately) has fstream.h but doens't
>show any fstream in it.

Class fstream, a file stream which allows both input and output, has
always been part of C++ iostreams. If the draft of 1/94 didn't include
it, that was an error.

BTW, don't try to use anything older than the public-comment version of the
draft for questions about the C++ library. The library section has been very
volatile and undergone many rewrites.  Changes from now on should be relatively
minor. (The public-comment version of the draft will be available for ftp soon.)
---
Steve Clamage, stephen.clamage@eng.sun.com

Steve Clamage (clamage@Eng.Sun.COM) wrote:
>  In article 4uf@darkstar.UCSC.EDU, ray@cse.ucsc.edu (Ray Swartz) writes:
>  >Borland 4.5 C++ compiler has fstream types.  The draft standard
>  >I have (from 1/94, unfortunately) has fstream.h but doens't
>  >show any fstream in it.

>  Class fstream, a file stream which allows both input and output, has
>  always been part of C++ iostreams. If the draft of 1/94 didn't include
>  it, that was an error.

AFAIK, bidirectional classes like fstream have been removed and will NOT
be part of the standard. fstream is not in the draft of 2/95.

You can use separate istream / ostream objects instead wich use a common
streambuf.

--
+----------------------------------+
|          Bernd Eggink            |
|    Rechenzentrum Uni Hamburg     |
| admin@rzaix13.rrz.uni-hamburg.de |
+----------------------------------+

In article kpj@rzsun02.rrz.uni-hamburg.de, admin@rzaix13.uni-hamburg.de (Bernd Eggink) writes:
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>>  In article 4uf@darkstar.UCSC.EDU, ray@cse.ucsc.edu (Ray Swartz) writes:
>>  >Borland 4.5 C++ compiler has fstream types.  The draft standard
>>  >I have (from 1/94, unfortunately) has fstream.h but doens't
>>  >show any fstream in it.
>
>>  Class fstream, a file stream which allows both input and output, has
>>  always been part of C++ iostreams. If the draft of 1/94 didn't include
>>  it, that was an error.
>
>AFAIK, bidirectional classes like fstream have been removed and will NOT
>be part of the standard. fstream is not in the draft of 2/95.
>
>You can use separate istream / ostream objects instead wich use a common
>streambuf.

Well, I blew it. This topic went back and forth in the C++ Committee,
and I was remembering what I and some others wanted (which was not
to break existing programs unnecessarily), instead of what eventually
got into the draft.

Bernd is quite right, and Ray's concern was well-founded.

If there is a public outcry to put the bidirectional classes back into
the standard, I believe that could happen. I don't believe there was any
strong technical reason to remove them, only a desire to remove things
that weren't necessary.

But even if bidirectional classes don't make it into the standard, I
imagine vendors will continue to supply them in order to keep customers happy.

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