>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) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost