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: Giel van Schijndel (Giel.vanSchijndel_at_[hidden])
Date: 2015-10-28 13:44:51

On 28/10/15 18:03, Giel van Schijndel wrote:
> On 28/10/15 17:25, Bo Persson wrote:
>> 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?
> That would return 'true' because, with this option, 'wchar_t' and
> 'unsigned short' aren't distinguishable anymore. I don't think that's a
> problem because is_character_type is only used as an internal
> meta-function inside boost::log::aux::code_convert and those conversions
> still make sense if 'wchar_t' is 'unsigned short'.
>
I just got a personal reply from Andrey. Apparently it's already fixed
(in a slightly expanded way of my intended solution strategy) and
present on github [1].

[1]:
https://github.com/boostorg/log/commit/44ef1095051f389931693f5117e404ffe22b9a56#diff-b4fb87ad4122b580a8d5e16376dfcafaL43

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel