Re: [Boost-users] Re: Config question: BOOST_NO_INTRINSIC_WCHAR_T(Intel7.1)

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-04-29 04:20:29

Christopher D. Russell writes:
> Some additional information pertaining to BOOST_NO_INTRINSIC_WCHAR_T using
> the Intel C++ 7.1 compiler in my MSVC 6 SP6 environment:
> 
> Using Boost v1.31.0 + STLport v5.0-125 + Intel C++ v7.1 (I updated to build
> 20030910Z) inside of MSVC 6 SP6 with a fairly recent MS Platform SDK, I
> simply could not get boost/config/compiler/intel.hpp to send me down the road
> to glory.

In short, if you are running Intel in MSVC6 compatibility-mode and you are not
compiling through bjam, you have to define BOOST_NO_INTRINSIC_WCHAR_T yourself
-- either through command line or in the user config. If you are using bjam, 
the Intel toolset (http://tinyurl.com/2codz) does that for you.

> 
> Inside of config/compiler/intel.hpp, _WCHAR_T_DEFINED is defined resulting in
> BOOST_NO_INTRINSIC_WCHAR_T not being set. Subsequently, this results in the
> compile-time error:
> 
> boost/type_traits/is_integral.hpp(38): error: class
> "boost::is_integral<unsigned short>" has already been defined
> 
> Per "Compiler errors with Intel 7.1 and type_traits"
> (http://lists.boost.org/MailArchives/boost/msg53033.php), specifically John
> Maddock's reply (http://lists.boost.org/MailArchives/boost/msg53121.php), I
> short-circuited the logic in config/compiler/intel.hpp and explicitly defined
> BOOST_NO_INTRINSIC_WCHAR_T in config/user.hpp. This seems to work acceptably
> for this project. But I'm not at all comfortable with this solution because I
> really don't understand what the fundamental issue is with all this wchar_t
> stuff.
> 
> Forgive my ignorance but if, with my current working config, if I declare a
> wchar_t type in my code I will get a 16-bit UCS-2 character. Correct? Having
> now poured over all postings related to this subject in the archive, I have
> an inkling that the root of all this stems from the way the compiler handles
> type aliasing? 

Yes, more or less.

> That is, with BOOST_NO_INTRINSIC_WCHAR_T a defined a wchar_t is actually an 
> alias for an unsigned int 

More likely 'unsigned short', but otherwise yes. 

> whereas in the case
> !defined(BOOST_NO_INTRINSIC_WCHAR_T), the compiler treats wchar_t as an
> intrinsic type? 

Yes. Or, rather, to be precisely clear, BOOST_NO_INTRINSIC_WCHAR_T _indicates_ 
to the Boost code that on the particular compiler/configuration 'wchar_t' is 
simply an alias for some other built-in integral type. It doesn't change the 
compiler's behavior.

> And from this we get these template specialization errors? 

Yep.

--
Aleksey Gurtovoy
MetaCommunications Engineering