Re: [boost] Re: Better Intel-Win32 support

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-06-04 14:25:22

At 07:58 AM 6/4/2003, John Maddock wrote:

 >
 >> That will certainly work, but you shouldn't have to do that since the
 >> compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier
 >this
 >> afternoon I am able to compile some non-boost code correctly which had
 >> previously be failing.
 >
 >Just let me jump in here: you absolutely can not use _WCHAR_T_DEFINED to
 >detect native wchar_t support: the windows headers will define this when
 >wchar_t has been defined as a typedef (and wchar_t is not a native type).
 >There appears to be no way to actually tell whether wchar_t is a native
 >type or not with Intel.

Gak! These compiler vendors are going to drive us all crazy! What do they 
expect us to do, use ESP to know what compiler options are set?

So this is yet another case (like /Qoption,c,--arg_dep_lookup) where Boost 
config code just has to assume the option has been set.

We need to figure out a way to document what options users are expected to 
set. It would be great if it were automatic. Perhaps there could be a link 
on the regression test status that showed the options used for config_info.

Hum... I inadvertently ran today's config_info test with the bjam -d2 
option, which causes the compiler invocation line to be reported as a 
warning. Has the side effect of allowing users to inspect the switches. 
Maybe we should do that all the time.

 >One other point: turning wchar_t support on may cause linker errors 
because
 >you have now changed the name mangling of functions that take wchar_t as 
an
 >argument - I don't know for sure but I would expect this to affect the 
std
 >lib.

Yes, I'd think so too. But in practice it doesn't seem to be hurting us. 
Right now on the Win32 tests, wchar_t support is turned on for como-win32, 
intel-win32, and VC++ 7.0. It doesn't seem to be hurting; in fact we get 
better results with wchar_t support on than off.

--Beman