RE: [boost] Re: lexical_cast issue

From: Drazen DOTLIC (Drazen.Dotlic_at_[hidden])
Date: 2003-07-23 04:45:59

> The problem, IIRC, is that if wchar_t is just a synonym for 
> unsigned short, then unless the wide character handling is 
> disabled in lexical_cast, it will give errors if it's used 
> with unsigned short (such as in the Date/Time library), and 
> people weren't too happy about that, understandably. The 
> problem is that it then thinks unsigned short is wchar_t 
> (i.e. a character), and therefore doesn't work correctly.

I completely forgot about other boost libraries depending on
lexical_cast - I was only looking at the lexical_cast's dependencies
_toward_ other boost libraries. Thanks for pointing this out.
 
> This problem surfaced after the 1.30 release, so we changed 
> the CVS version to disable wide character handling, unless 
> wchar_t is an intrinsic type. On some platforms it may not be 
> possible to reliable detect intrinsic wchar_t or not (such as 
> some versions of Intel C++ on Windows), so Boost.Config errs 
> on the side of safety, disabling it in that case.

Well, it is properly detected and disabled :( in our case, and now I see
that we can't avoid that. Actually we can, but then we will break other
boost libraries, which currently (for us) is not an issue, but might
soon be.
 
> It does work; it just doesn't treat unsigned short/wchar_t as 
> wchar_t, in that case. Would you like lexical_cast to treat 
> wchar_t (when synonym for unsigned short) as wchar_t? As 
> mentioned, that breaks other libraries, which assume that 
> unsigned short is an integer, not a character.

Seems like I will have to dig in again and do my best to patch our
compilation to treat wchar_t as it should be, native type. Millions of
lines of source code affected by this change are definitely discouraging
me, though.

Thanks for your time, it is very appreciated,

Drazen