From: Mark D. Anderson (mda_at_[hidden])
Date: 2001-10-13 20:12:54
(Aside: i sent this yesterday afternoon via the web interface, and it apparently got lost.
there were no posts at all between noon and 4pm recorded yesterday.
is anyone else losing posts? is anyone else using the web interface?
i sent another note too but didn't keep a copy of that one, so i guess it
is lost to posterity.)
Ronald Garcia says:
> I just uploaded a tarball to the boost files section
is there any relation between your work and vladimir prus,
who uploaded some codecvt code about a month ago?
is there a reason not to introduce a fixed typedef boost::ucs4_t,
as a uint32_t?
then there could be a version of this that would work
on any platform.
as you know, on win32 (and elsewhere?) wchar_t is 16bits,
so you are currently forcing platform-specific specialization.
even on systems where wchar_t is 32bits, there are no guarantees
that the implementation character set is unicode.
even if __STDC_ISO_10646__ is defined, i'm not sure if that
strictly guarantees that the values are comparable with cast
ints, because it (i think) is still implementation defined
what the signedness and endianness is of wchar_t storage,
even if the code value space is unicode.
can you make a version of this which conforms to codecvt_byname?
can you somehow integrate your iterator and codecvt, so that
one is implemented in terms of the other?
i think there is still a use for the iterator model, for when
you want to keep your buffer in the external encoding.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk