[boost] Re: lexical_cast and boost-1.30

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-03-14 09:33:36

Kevlin Henney wrote:
> In article
> <Pine.LNX.4.44.0303131439490.24179-100000_at_boyne.cs.ualberta.c
> a>, Dave Gomboc <dave_at_[hidden]> 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.