basic_filebuf<charT,traits> only has a default ctor.  This makes
for some very tedious porting of older iostreams.  How about
adding a ctor that takes a FILE* as an argument.  This will aid the
derivation model and allow a migration path for all the people who
use the nasty attach method.

Tom Maguire
tmaguire@us.ibm.com
---
[ 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
]

Hi,
Tom Maguire (tmaguire@us.ibm.com) wrote:
: basic_filebuf<charT,traits> only has a default ctor.  This makes
: for some very tedious porting of older iostreams.  How about
: adding a ctor that takes a FILE* as an argument.  This will aid the
: derivation model and allow a migration path for all the people who
: use the nasty attach method.

Basically your request was submitted as bug report during the
commenting phase(CD2) and the issue was discussed in London in the
IOSterams/locales working group at length. At first, it looked like
such a feature would make it into the standard but it turned out to be
much more troublesome than expected. Thus, neither an attach method
taking a FILE* as argument nor a corresponding open() function or a
constructor was added.

The basic killer arguments were:
- it is sufficent easy to create an own steambuf with the specified
  feature (eg. the problems with character conversion do not exist
  since FILE* writes 'char's; hence the only major problem in
  implementing 'basic_filebuf' disappears).

- the semantics what happens to the 'FILE' after it is passed to a
  'basic_filebuf' would probably be non-intuitive: How should buffering
  be handled?

- the requirement to be to pass a 'FILE*' as constructor argument (or
  as an argument to 'open()' or 'attach()') would probably render
  implementation which do not delegate requests to a 'FILE*'
  inefficient.

The arguments are listed in the order of importance. The latter is just
a feeling and it may be possible to implement things efficiently.
However, this would seriously compilicate that already non-trivial
implementation of 'basic_filebuf'.  This compilication does not exist
for self implemented classes using 'FILE*' because these would probably
not need the code conversion stuff.

The book "The Draft Standard C++ Library", P.J.Plauger, Prentice Hall,
includes an implementation which delegates all requests to a 'FILE*'.
It can be easily extended to fit into the templatized environment and
to support necessary methods involving a 'FILE*' (if it does not
already). I also think that the current libg++ comes with a class
called 'stdiobuf' which does basically the same thing.
--
<mailto:dietmar.kuehl@uni-konstanz.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ 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
]