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