Kevlin Henney wrote: > 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 > ;-)
I am not trying to change lexical_cast at this late date since it must get out the door with 1.30, but this goes back to a comment I made quite a while ago about the two different versions of wchar_t on VC7 and the possible need to support both in Boost. I think it was briefly discussed by others but, more or less, shelved as an important issue. The default in VC7 is still the Microsoft version as opposed to the C++ standard version of wchar_t. For header-file only implementations, whichever option is used when the header file is included in a module should theoretically work in Boost implementations. However if Boost has a macro for VC7 which says that wchar_t is not supported natively, then wchar_t may not work in Boost implementations. For library implementations which use wchar_t in any way, my original comment had to do whether different versions of libraries for VC7 should be built for supporting the two different versions of wchar_t in VC7. If one distributes a library with support only for one of the two versions of wchar_t in VC7, it will not work with modules built with the other version of wchar_t in VC7 ( lots of linker mismatches and error messages ). Of course instructions may be given to rebuild the library manually so that it works. Yes, it's a PITA because of MS's long-standing non-support for the native C++ wchar_t in their VC++ compiler. I believe the same problem will exist for 7.1 and until, if ever, MS pulls the plug on their non-standard wchar_t support. The only reason I bring this up again is that Boost may have some pretty angry MS programmers when they find out, at linker time for library implementations and at compile time for non-library implementations if a blocking Boost macro is in place, that wchar_t support does not exist for a given implementation. Perhaps this issue should be addresses once 1.30 gets out the door. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
