🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2504

Re: Question re: ostream::operator<<(wchar_t)

#2504
From: J. Kanze
Date: Fri, 10 Nov 1995 12:43
53 lines
3370 bytes
Shankar Unni (shankar@boris.engr.sgi.com) wrote:
|> I have to implement an ostream::operator<<(wchar_t) (for a USL-derived
|> iostream library, with a builtin wchar_t type), and ran into the question:
|> exactly what should this operator write to the stream?

I'm going out on a limb here, since I've not actually studied this point
in detail in the standard, but...

Logically, this would depend on the parameter of the last imbue function
(the file-specific locale).  For a French locale, for example, I would
expect that the routine would output ISO 8859-1, and set the fail bit if
the parameter had no representation in this code.  In a Japanese locale,
of course, the locale would have to specify which of the different
encoding conventions should be used.

Alternatively, an implementation could, like Plan 9, simply decide once
and for all which external representation would be used.  (Of course,
this means that if the text is in French, for example, I probably will
not be able to read the file on any other machine.)

(Or is the entire embue mechanism only there to choose between `.' and
`,' for the decimal?)

|> >From the Sep 95 draft, it seems that (page 27-51)
|> basic_ostream<wchar_t>::operator<<(wchar_t) should convert its argument
|> with a "%c" printf specifier. But surely this is a mistake or an oversight,
|> since it doesn't mean anything for wchar_t: the wchar_t will be cast to a
|> "char" and written, destroying its value.

I would guess that if this were the case, the if casting the character
causes loss of value, the fail bit should be set.  In fact, I suspect
(hope?) that this is just text from an earlier version, which hasn't
been reworked yet.

|> My question is: are the input and output operators for wchar_t-based
|> streams required to do this (silly, IMHO) behavior? Or does it make
|> more sense for them to read and write multi-byte strings, converting
|> to / from wchar_t as needed (which is what the scanf/printf "%C" and
|> "%S" operators do)?

I would expect this, with the choice of multi-byte encoding
implementation defined, preferably configured by the imbue function, or
eventually by the instantiation of the template.  (I'll really have to
check the standard, to see which.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID: <47val3$8tc@gabi.gabi-soft.fr>
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
References: <9511081145.ZM2073@boris.engr.sgi.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
Date: 10 Nov 95 12:43:34 GMT
Approved: fjh@cs.mu.oz.au
From: kanze@gabi-soft.fr (J. Kanze)
Newsgroups: comp.std.c++
Subject: Re: Question re: ostream::operator<<(wchar_t)
X-Original-Date: 10 Nov 1995 11:48:03 +0100
Organization: GABI Software, Sarl.
Message-ID: <47val3$8tc@gabi.gabi-soft.fr>
References: <9511081145.ZM2073@boris.engr.sgi.com>
X-Newsreader: TIN [version 1.2 PL2]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMKNJouEDnX0m9pzZAQGAbgGAn/7u9QSeH08ZgokrIrplSxmCObBu4XiY
 hcaRaT5CLgu/SMexJmaZUF4bs7h6irDW
 =vLmN