From: David Abrahams (dave_at_[hidden])
Date: 2004-01-22 18:39:23
"Giovanni Bajo" <giovannibajo_at_[hidden]> writes:
> 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
> 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
> 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
> 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).
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk