[boost] Re: ICC wchar_t proposed solution

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-22 18:39:23

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

> Hello,
>
> I investigated the problem with ICC and wchar_t. I'll recap the main points:
>
> - ICC (Win32) defines a preprocessor symbol _WCHAR_T_DEFINED if it's called
> with /Zc:wchar_t (that is: if wchar_t is a native type).
>
> - Basic include files under Win32 have code like this:
>
> #ifndef _WCHAR_T_DEFINED
> typedef unsigned short wchar_t;
> #define _WCHAR_T_DEFINED
> #endif
>
> which basically makes _WCHAR_T_DEFINED useless.
>
> - 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.

> - Our current code fails to understand that _WCHAR_T_DEFINED is
> useless as-is.
>
> 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.

> Many people (including myself) have stumbled upon this, because they
> try to manually compile code relying on Boost with the default
> settings.
>
> The solution is easy: I had to check, but it turns out that _WCHAR_T_DEFINED
> expands to "1" (ICC71) or "2" (ICC80) when defined by ICC itself (that is, when
> wchar_t is a native type), while the standard libraries always define it with
> no value (as shown above). 

Very interesting!

> The patch attacched to this mail relies on this minor difference to
> understand whether wchar_t is a native type or just a
> typedef. Notice that the code will indifferently work when included
> either BEFORE or AFTER the standard headers, which is a major pro. I
> verified that this lets me compile the uBLAS tests with or without
> /Zc:wchar_t, and with different behaviours (that is, the code *does*
> detect when wchar_t is a native type and when it is not).
>
> 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.

> Does this look OK to everyone else? I'd be willing to commit this to both the
> branch and the trunk.

Except for the point above and the question about lying in the
affirmative, I like the general approach.

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