[boost] Re: lexical_cast issue

From: tslettebo_at_[hidden]
Date: 2003-07-23 00:08:22

>From: Drazen DOTLIC

(Sorry for the late reply - I've recently started a new job, and moved, so I've been a little busy)

>I've encountered something I can not claim to be a problem, but would
>like to consult with you (or at least author of lexical_cast). We are
>using VC7.1, boost from CVS few weeks old, and building Unicode
>applications. Naturally, we use std::wstring all over the place, and
>lexical_cast on some of the places.
>But boost deliberately forbids wide character usage in lexical_cast
>unless _NATIVE_WCHAR_T_DEFINED is defined - from
>config/compiler/visualc.hpp:
>#ifndef _NATIVE_WCHAR_T_DEFINED
>#  define BOOST_NO_INTRINSIC_WCHAR_T
>#endif

>And then in lexical_cast.hpp:
>#if defined(BOOST_NO_STRINGSTREAM) || \
>    defined(BOOST_NO_STD_WSTRING) || \
>    defined(BOOST_NO_STD_LOCALE) || \
>    defined(BOOST_NO_INTRINSIC_WCHAR_T)
>#define DISABLE_WIDE_CHAR_SUPPORT
>#endif

>Why is this? I don't see big problem in the fact that wchar_t is >just a typedef _in this context_?

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.

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.

>yes, I am
>aware of problems, and would gladly turn on /Zc:wchar_t compiler >option
>on, but I can't - some of the 3rd party open source libraries that we
>use in our projects break, and fixing them would be a pain in the >ass,
>not to mention maintenance later.
>Now, I see that we can't just disable the first of the above >mentioned
>macros, because then a lot of other code depending on the difference
>between unsinged short and wchar_t would fail, but maybe we could >patch
>lexical_cast to still work even when wchar_t is not a real type?

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.

>I hope I wasn't too chaotic and you understood my question.

Sure. :)

Regards,

Terje

(Day-to-day maintainer of lexical_cast for Kevlin Henney, as he isn't subscribed to the list)