[boost] Re: uBLAS/MPL failures with ICC?

From: Giovanni Bajo (giovannibajo_at_[hidden])
Date: 2004-01-12 07:44:04

Michael Stevens wrote:

>> I was trying to compile uBLAS bench4 with ICC under Windows (either
>> 7.1 or
>> 8.0), and I get this:
>>
>> bench4.cpp
>> e:\boost\boost/mpl/aux_/typeof.hpp(66): error: cannot overload
>> functions distinguished by return type alone
>>   BOOST_MPL_AUX_REGISTER_TYPE(7, unsigned short)
>>   ^
>>
>> Is this known?
>
>
> I'm trying to reproduce this. Which Boost version does this relate to:
> CVS, CVS 1_31_0 branch ?

It's a CVS version taken from HEAD 2 days before the branch was created.

I traced it down: it's related to the known problem with ICC and wchar_t. In
fact, it deseappears if I specify /Zc:wchar_t (use intrinsic wchar_t) on the
command line. The point is that we have a configuration bug here. Let me quote
this message for you which I sent to the spirit-devel list:

-------------------------------------------------------------------------------
---------------------------
Hartmut Kaiser wrote:

[The problem is about some failures of Spirit with ICL + STLPort, under Win32]
> Ok, I've tracked the problem down. It is a clash of a preprocessor
> defined symbol (_WCHAR_T_DEFINED).
>
> If this symbol is not defined, Boost.Config defines the
> BOOST_NO_INTRINSIC_WCHAR_T symbol, which allows to avoid unsigned int
> <--> wchar_t related issues.
>
> But this symbol is defined by the VC6 std C++ headers, whenever a
> 'typedef unsigned int wchar_t;' is issued. So the Boost.Config does
> not defines the BOOST_NO_INTRINSIC_WCHAR_T, which leads to
> compilations errors (if the Intel commandline switch -Zc:wchar_t
> (makes wchar_t a intrinsic type) is not specified) and compiles
> silently ok, if it is.
>
> But STLPort is compiled without the -Zc:wchar_t, so that there is no
> std::numeric_limits<> specialisation for wchar_t in the STL. This
> leads to the assertion in the range_run<wchar_t> code.

If _WCHAR_T_DEFINED/_WCHAR_T are library symbols, they must not be checked in
config/compiler/intel.hpp, because in this way they appear to be compiler magic
symbols. Once they are moved to config/stdlib/dinkumware.hpp and
config/stdlib/libstdcpp3.hpp respectively (where they belong), it appears clear
that you simply need something similar in config/stdlib/stlport.hpp as well.

I suggest something like:

#if !defined(_STLP_HAS_WCHAR_T) || defined(_STLP_WCHAR_T_IS_USHORT)
# ifndef BOOST_NO_INTRINSIC_WCHAR_T
#   define BOOST_NO_INTRINSIC_WCHAR_T
# endif
#endif

The patch means that Boost cannot assume that wchar_t is an intrinsic if the
standard library was compiled/configured thinking that it's not: in this case,
we would fail because of the missing std:: specializations. It's basically the
same thing which is done by testing _WCHAR_T_DEFINED (dinkumware symbol), or
_WCHAR_T (libstdcpp3 symbol), we're just using the STLPort spelling of it.
-------------------------------------------------------------------------------
---------------------------

Does this look ok to you? I can prepare a patch for submission, but I need help
with the testing.
-- 
Giovanni Bajo