[boost] Re: lexical_cast and boost-1.30

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

Kevlin Henney wrote:
> In article <b4sp1d$i5p$1_at_[hidden]>, Edward Diener
> <eddielee_at_[hidden]> writes
>>
>> 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.
>
> I think the issue is not really related to lexical_cast. lexical_cast
> works just fine on VC7 supporting non-native wchar_t. However, to be
> sure of more universal support using the BOOST_ config macros, any
> compiler that does not have a native wchar_t is excluded from wide-
> character support under the current version of lexical_cast.

Will lexical_cast work correctly if the VC7+ end-user changes the option to
C++ native wchar_t ? If not, you might get some complaints from end-users
who are migrating away from the MS version of wchar_t to the C++ standard
version on VC7+. I think others also brought up the fact that they want
Boost to support C++ as much as possible vs. a compiler's non-standard
version of C++. Again I realize it is probably too late to change things for
1.30, as everyone wants to get this out without further delays, but for the
future this issue needs to be addressed. For better or worse, there are many
VC++ programmers out there and MS is definitely pushing VC7.1 as a Boost
compatible implementation.

>
> In the next version we can perhaps be more precise, but for the moment
> the default is that lexical_cast compiles in the most conservative
> way.
>
>> 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.
>
> Sounds reasonable. Which Boost libraries currently use wchar_t but are
> not 100% header based?

I know of Regex++. There may be other Boost libraries which other people
know about. I am pretty sure John Maddock is aware of the issue, but other
library implementors who use wchar_t may not be.