Boost logo

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, gregod at, cpdaniel at, john at