Re: [boost] Boost.Log 1.59.0 incompatible with MSVC option /Zc:wchar_t-

Subject: Re: [boost] Boost.Log 1.59.0 incompatible with MSVC option /Zc:wchar_t-
From: Bo Persson (bop_at_[hidden])
Date: 2015-10-28 12:25:26

On 2015-10-28 14:39, Giel van Schijndel wrote:
> Hi,
>
> I'm trying to build Boost.Log on MSVC9 (aka Visual Studio 2008) with the
> [/Zc:wchar_t-][1] option (necessary due to a vendor's SDK we're using).
> Unfortunately this fails to build.
>
> The mentioned option turns wchar_t into a typedef to unsigned short
> (i.e. it's not longer a distinct type).
>
> TLDR:
> My question _why_ is boost::log::aux::is_character_type<wchar_t>
> excluded when BOOST_NO_INTRINSIC_WCHAR_T is #defined? I see no harm in
> including it unconditionally.
>
> For some reason however, the template meta-function
> boost::log::aux::is_character_type<T>'s specialisation for wchar_t is
> guarded by !defined(BOOST_NO_INTRINSIC_WCHAR_T) [2]. This means wchar_t
> is _not_ regarded as a character type and prevents instantiation of the
> boost::log::aux::code_convert functions [3] which are _still_ used.
>
> The only reason I can see for excluding this is to prevent a _potential_
> conflict with multiple specialisations for the same type (because of the
> typedef nature of wchar_t). But the only other specialisation that could
> potentially give a conflict is the one for char16_t, and that's mandated
> by C++11 to be a distinct type (AFAIK the only reason why wchar_t isn't
> always distinct type on Windows/MSVC is because they introduced the type
> pre-standardisation, so I see no reason why that mistake should be
> repeated for char16_t).
>

What do you expect boost::log::aux::is_character_type<unsigned short> to 
return with this setting?

Bo Persson