Re: [boost] [date_time][lexical_cast] boost configuration issue

From: John Maddock (john_at_[hidden])
Date: 2005-05-06 04:53:08

>>    I think I found a configuration issue while building boost 1.32.0 with 
>> VC .Net 2003 (VC71) using STLport 5.0 beta (latest from cvs STLPORT_5_0 
>> branch). Maybe someone already notive this problem but the latest boost 
>> CVS version still show it.
>>
>>    With the STLport lib the macro configuration is :
>>
>> - BOOST_NO_INTRINSIC_WCHAR_T defined
>> - BOOST_NO_STD_WSTRING _not_ defined, wstring are supported
>>
>>    Thanks to the BOOST_NO_STD_WSTRING macro the date_time lib instanciate 
>> code for wstring specific type. For instance in 
>> libs/date_time/src/gregorian/greg_month.cpp you will find a block of code 
>> in a #ifndef BOOST_NO_STD_WSTRING block.
>>
>>    The date_time lib use the lexical_cast tool. But the lexical_cast tool 
>> do not care about BOOST_NO_STD_WSTRING and rather check, among other 
>> macros, BOOST_NO_INTRINSIC_WCHAR_T and so do not grant the necessary 
>> specialization for wchar_t and wstring. The error message is then 
>> something like:
>>
>> D:\boost_1_32_0\boost/lexical_cast.hpp(137): error: no operator "<<" 
>> matches these operands operand types are: 
>> std::basic_stringstream<wchar_t, std::char_traits<wchar_t> , 
>> std::allocator<wchar_t> > << const std::basic_string<char, 
>> std::char_traits<char> , std::allocator<char>> return stream << input;
>>
>> Sorry for not having the accurate message but I have the compiler on an 
>> other computer.
>
> Thanks, I can reproduce that with plain VC++ when building date_time 
> without the /Zc:wchar_t switch, I'll look into possible fixes for 
> lexical_cast,

Unfortunately this looks "unfixable" at present: I don't want to disable 
std::wstring Boost-wide when wchar_t is not a native type, as that will 
break other libraries (regex for one).  But I haven't been able to force 
lexical_cast to work when wchar_t is not a native type either (it gets 
confused as to whether it's reading/writing an integer, or a character).  So 
for now the only solution appears to be "use /Zc:wchar_t to compile 
date_time and if necessary, your code as well", I realise that's not ideal 
though...

John.