In article <[EMAIL PROTECTED] a>, Dave Gomboc <[EMAIL PROTECTED]> writes > >I would vote to fix lexical_cast before release.
Looking at the regression tests from last night, that appears to have happened. >Frankly, wchar_t support in lexical_cast isn't as important as fixing the >space problem, I'd rather the fix go in even if it regresses in this area >-- unless someone pipes up to say they are actually USING wchar_t and >lexical_cast on a compiler that won't grok the new code. And if there is >such a person, then I'd appreciate the ugly hack of including both >versions with #ifdefs. My sense is that only a few people have commented on lack of wchar_t support, whereas space is the final frontier that has hit many more. At the cost of a little duplicate code and a #ifdef the newer version is much more reticent about its support for wchar_t. Any compiler that does not fully support built-in wchar_t, wstring and wide-character streams does not receive any support at all for wchar_t, even though the code might kind of work in some cases, eg VC7 compiled without native wchar_t support no longer offers support for wide-character lexical_cast, even though the tests pass 100% in that case. So if anyone now complains about apparent lack of wchar_t support in lexical_cast, they should contact their compiler and library vendors rather than the Boost list ;-) Kevlin ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
