[boost] Re: ICC wchar_t proposed solution

From: Giovanni Bajo (giovannibajo_at_[hidden])
Date: 2004-01-23 05:10:45

David Abrahams wrote:

>> - http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864 means
>> that we cannot rely on wchar_t for ICC before 7.0, so we should
>> always define BOOST_NO_INTRINSIC_WCHAR_T for it.
>
> That's not clear to me.  Anything we say is a lie under some
> circumstance for ICC6, right?  Is it better to lie in the affirmative?
> We should at least give people a macro they can define on the
> command-line to undo the lie.

More than a lie, the problem seems that wchar_t support is buggy. I don't think
we're better off lieing with the affermative: if we say that wchar_t is a
native type when it's not, we will break existing code (specializations with
wchar_t conflicts with specializations with unsigned short).
If my code is committed, people can still define "_WCHAR_T_DEFINED = 1" on the
command line and force Boost into believing that wchar_t is a native type. We
can document it this way, or if you prefer BOOST_INTEL_FORCE_WCHAR_T.
Anyway, I don't have access to Intel 6.x, so I can't really test it. My patch
(conservatively) doesn't modify the Intel 6.x configuration.

>> We basically have:
>>
>> #ifndef _WCHAR_T_DEFINED
>> #define BOOST_NO_INTRINSIC_WCHAR_T
>> #endif
>>
>> Net result is that our intel-win32 toolset is totally broken if we
>> don't specify /Zc:wchar_t.
>
> How so?  /Zc:wchar_t is specified by the toolset itself.

I wrote "toolset" but I meant "compiler". If you open your own project with VC
IDE and try to compile something that includes ublas.hpp (or you try to compile
it from the command line), it's broken. The "toolset" as in the build system
works because it forces /Zc:wchar_t, and in fact I stumbled upon my problem
trying to compile from the command line.

With my patch, Intel C++ can be used also without /Zc:wchar_t.

>> The other hunk of the patch fixes a compatibility issue with
>> STLport. In fact, there are many versions of STLport which are
>> pre-configured with _STLP_WCHAR_T_IS_USHORT, even if the compiler
>> was making it a builtin type. The point is that we (Boost) must
>> acknowledge if STLport was configured without wchar_t support and
>> disable our support as well. Otherwise, we will fail because we
>> wouldn't find specializations such as basic_string<wchar_t> and the
>> likes. Hartmut verified for me that this patch fixes the regression
>> failures in Spirit in the intel-stlport-win32 toolset.
>
> I think we'd better have a separate macro which determines whether
> the standard library is supporting wchar_t.

I agree that, in the longer run, that's the correct solution, but I don't have
resources to implement it now, and change the existing codebase. Meanwhile, my
solution should help fixing the problems we see.
-- 
Giovanni Bajo