Boost logo

Boost Users :

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 ( 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"
> (, specifically John
> Maddock's reply (, 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?


Aleksey Gurtovoy
MetaCommunications Engineering

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at