Imbuing streams to auto-codecvt [was Re: _M_underflow_common missing]

[Brad Spencer]

On Tue, Sep 03, 2002 at 06:48:23PM -0300, Brad Spencer wrote:
> I came across this same problem from a different angle while trying to
> write code that did implicit ShiftJIS-to-UCS4 conversion as part of an
> ifstream.  I have no trouble reading 'char' directly and throwing it
> through codecvt::in(), but that's way less cool than just imbuing the
> stream with a locale that knows how to do it on the fly (i.e. properly).
> 
> The best I've got so far is a bad_cast being thrown or in always being
> the empty string and then hitting end of file.  It can't be this
> hard.

I've managed to cobble enough together to get it to work.  I traced my
std::bad_cast to my cut-and-paste of the
basic_filebuf::_M_underflow_common code from fstream.cc.  Because I
was not using the extension enc_filebuf, my __codecvt_type was wrong.
I changed use_facet<__codecvt_type> to use_facet<my_facet> and all
works well (or so it seems).

I am determined to do this "properly" however, while making use of the
__enc_traits helper.

I found a reference in an old thread[1] where Benjamin says:

> The biggest problem that I ran into is that the design specified by
> the standard assumes that the type of conversion (and therefore the
> source and destination encoding) can be controlled by the types used
> as the template arguments.

I think that my approach of making a subclass of __enc_traits that
semi-hardwires the locale names is a reasonable approach.  If the
standard's design assumes this, then maybe I can work with it to make
everything happen.

(I think) I'd love to be able to just say:

  std::wifstream file("somefile");
  file.imbue(user_locale);
  std::wstring x;
  file >> x;

but, then I might actually _want_ the types to be different for
different encodings, so I _might_ want:

  std::basic_ifstream<wchar_t, some_user_traits> file("somefile");
  file.imbue(user_locale);
  std::basic_string<wchar_t, some_user_traits> x;
  file >> x;

The more I think about it, the more I like the second way better.  The
problem shows up in the partial specializations of codecvt and
basic_filebuf::_M_overflow_common.  One I can work around with a
subclass, and the other a cut-and-paste that's dependent on the
current implementation details, but I consider this to be Too Ugly.  

If there is no interest on this list, I can stop posting about this :)
Thanks.  

[1] http://gcc.gnu.org/ml/libstdc++/2001-02/msg00254.html


-- 
-----------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
  Systems Architect | InfoInterActive Corp. | An AOL Company