[boost] Re: ICC wchar_t proposed solution

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-23 08:07:47

"Giovanni Bajo" <giovannibajo_at_[hidden]> writes:

> 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: 

I think you mean the opposite of what I meant here.  An affirmative
for BOOST_NO_INTRINSIC_WCHAR_T would mean that we're saying "there's
no intrinsic wchar_t"

> 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. 

Good.

> 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, 

I do.

> 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.

OK.

>>> 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.

OK.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com