Re: Does wstream make sense?
On Wednesday, 7 August 2013 19:49:49 UTC+1, Daniel wrote:
On Wednesday, August 7, 2013 9:32:29 AM UTC-4, James Kanze wrote:
If this is wstream, it was *not* introduced to support wchar_t
at the system level. Just the opposite: it was introduced to
support localization internally (e.g. where the characters you
want to output as digits aren't present in the single byte
encodings of char). It defines all system level IO in terms of
char, and defines how the wchar_t should be mapped to and from
char (in filebuf, so that you can write char, even though
everything upstream was in wchar_t).
Just for my own understanding, could you clarify where in the
wostream composition that char first appears? In
basic_filebuf<wchar_t>, the signatures of the put methods are
still wchar_t, and the buffer variable appears to be also an
array of wchar_t.
And in =A727.9.1.5, it explains how the wchar_t in the buffer are
converted to and from char so that they can be written or read.
(See the semantics of underflow and overflow.)
It's normal that all of the interfaces are wchar_t, since they
are there for the client code to use. The filebuf buffers the
characters as <charT>, when the buffer overflows, it converts
these to char (using the codecvt facet of the imbued local) in
order to write them, and when underflow occurs, it reads char,
then converts them to wchar_t (again, using the codecvt facet of
the imbued locale).
The same thing holds, sort of, for wide character streams in C.
(Sort of, because there is only one type of FILE*, you use
different functions for wide character IO and narrow character
IO, and the code conversion depends on the global locale, since
there are no imbued locales.)
--
James