|
Boost : |
From: James Porter (porterj_at_[hidden])
Date: 2007-09-27 15:12:25
On 9/27/07, Sebastian Redl <sebastian.redl_at_[hidden]> wrote:
>
> That has nothing to do with what basic_string<wchar_t> is, though,
> because that state is to be used when converting the string to an
> external encoding.
Well, clearly that state needs to know what the internal encoding is in the
first place, so they are related in some way. Ideally, I'd like to be able
to use the state_type for basic_string as one half of the shift state, with
the other half being the state_type for the target (say, an output stream).
Put those two together, and we could build a codecvt facet of the form:
codecvt<internal_char, external_char,
conversion_pair<internal_state_type, external_state_type> >
Doing it this way obviously wouldn't work with any of the I/O streams now,
since they require the char_traits to be the same, but perhaps we could
define a converting_stream type that creates the above codecvt facet
automatically and handles conversion.
In some sense, I suppose this is an abuse of char_traits<Ch>::state_type,
but I think it's the most backwards-compatible way. That is, if the internal
(string) and external (stream) encodings were the same, I/O would behave
like it does now (only hopefully in a more predictable/useful fashion when
dealing with Unicode).
- James
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk