A response to Herr Kuehl's comments and suggestions has been posted to
comp.lang.c++-moderated, and the originally posted URLs have been updated
with better (I hope) code that attempts to follow the suggestions.

Jeff




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

Hi,
Jeff Greif (jmg@spam-me-not.trivida.com) wrote:
> In my opinion, the basic_ofstream should have been more flexible -- it
> should allow parametrization based on the streambuf class it uses.  This
> would allow subclassing the filebuf
> class to handle issues like opening filenames specified in wide characters,
> and subclassing the
> basic_ofstream to add an overloading of the open() method which uses the
> filebuf subclass.

What would be the use of this flexibility? Implementing class
'basic_ofstream' is trivial! It takes just a few minutes and it is
only present for convenience anyway. It is just used at the point of
construction where the type is known, ie. it is not used in
polymorphic contexts. There, 'basic_ostream' is used instead. There is
actually no or at least very few use in reusing 'basic_ofstream' for
different stream buffers: It is just a convenience front end to a
specific stream buffer, nothing more!

What would be interesting to have is a separation of 'basic_filebuf'
into two classes. After all, it does two completely unrelated tasks:

- 'basic_filebuf' converts between an external representtion and an
  internal representation using the facet 'codecvt'
- 'basic_filebuf' opens, reads, writes, and closes files

The latter task, ie. accessing the file system, is actually trivial:
Implementing a new file buffer using some special file access
functions which operate more or less like the POSIX functions
'open()', 'read()', 'write()', ... is simple. That is, if you know how
to do the stream buffer stuff, it takes, well, half a day. Of course,
this moves completely outside of the standard.

The first task, doing the conversion between character encodings is,
to say the least, non-trivial (has anybody implemented it for a stream
buffer which allows buffering? if yes: Cool job!). Unfortunately, the
conversion stuff is folded into 'basic_filebuf'. If it were separated
into class, say 'convertbuf', which uses an appropriate abstraction
for files (basically a class encapsulating functions like 'read()',
'write()', 'seek()' but NOT 'open()' and 'close()': 'convertbuf' would
not be responsible for creating objects of this type), it would be
easy to create new file buffers. For example, this could then be used
to implement a file buffer using wide characters for the file names.

> I've put a completely conforming version of this scheme in
> http://www1.trivida.com/public/greif/FlexStream.h

The interfacees look indeed as if this could be conforming
implementation. However, the whole implementation is completely
environment specific! It would not work with any other implementation
than the one of Dinkumware.

However, here are some more notes:
- "using namespace std;" should *NEVER* go into a header file!
- The constructor of 'flex_ofstream' should pass the stream buffer
  not only to the immediate base class but also to the virtual base
  class 'basic_ios'. Actually, since 'basic_ios' is a virtual base class
  without a default constructor you should be forced by the system to
  supply this argument...
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl> >

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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 my opinion, the basic_ofstream should have been more flexible -- it
should allow parametrization based on the streambuf class it uses.  This
would allow subclassing the filebuf
class to handle issues like opening filenames specified in wide characters,
and subclassing the
basic_ofstream to add an overloading of the open() method which uses the
filebuf subclass.

I've put a completely conforming version of this scheme in
http://www1.trivida.com/public/greif/FlexStream.h

There is one (crucial) line of the file which is Win32-specific, but if your
OS offers any
reasonable way to open filenames specified as wide strings, you'll be able
to adapt it.

The main problem is that the flexible_ofstream is derived (just like
basic_ofstream) from
basic_ostream, so too much stuff has to be reimplemented (more or less
copied from basic_ofstream).  The wiring of the streambuf type into
basic_ofstream made it impossible for
me to figure out how to derive from basic_ofstream instead.

The implementation is only lightly tested (on Windows NT 4.0 SP3, using
MSVC++ 5.0 SP2) and is offered here as is, no warranty.  I'm interested in
hearing about bugs if you find any.  There is a sample test program in
http://www1.trivida.com/public/greif/flexstreamtest.cpp


Jeff

David R Tribble wrote in message
<364A0991.25DE@noSPAM.central.beasys.com>...
>
>Paul Grealish wrote:
>>> 'wofstream' is defined in the standard as:
>>> typedef basic_ofstream<wchar_t, char_traits<wchar_t> > wofstream;
>>>
>>> 'basic_ofstream' defines method 'open' as:
>>> void open(const char *s,
>>>           ios_base::openmode mode = ios_base::out | ios_base::trunc);
>>>
>>> Could anyone tell me why is there no version of 'open'
>>> that accepts a wide character (wchar_t*) filename?
>
.... further discussion omitted ...




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