|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-12 01:05:21
Daryle Walker wrote:
>> It was specifically requested that some Unicode/wchar_t support be added
>> before putting to CVS.
>
> That doesn't mean that you _have_ to do it. You can give the person who
> gave the request a (temporary) rejection notice.
Well, that was requested by the review manager (while wearing review manager
hat). So, given that I think it's possible to implement with little effort,
I'd rather implement this.
>> What 'cool-sounding idea' do you mean? What I proposed was that unicode
>> data is just passed though, without modification.
>
> I read messages in this thread about doing full-blown Unicode handling,
> and I've read about doing nothing (being as Unicode-ignorant as other
> text-processing Boost libraries). I wouldn't mind adding "wchar_t"
> support, without necessarily assuming that it's Unicode.
I still plan to assume wchar_t is unicode, until some user comes up with
problems in his real case.
>> Do you know specific case there wchar_t does not implicitly means
>> Unicode.
>
> Not personally, but that's about as relevant as asking for a platform
> whose
> "char" isn't 8 bits. (I've heard platforms like that have existed.)
I know one such platform which exists today, with 32-bit char. However, it
(1) still uses ascii
(2) you won't run string algrotithms on a DSP anyway
Yes, implementation is allowed to use randomly-permuted ascii encoding. The
point is that *if* user of such implementation really starts using
program_options, it would be possible to accomodate that.
- Volodya
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk