Boost.Log 1.59.0 incompatible with MSVC option /Zc:wchar_t-
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
#ifndef _NATIVE_WCHAR_T_DEFINED # define BOOST_NO_INTRINSIC_WCHAR_T #endif
[1]: https://msdn.microsoft.com/en-us/library/ms933181.aspx [2]: https://github.com/boostorg/log/blob/boost-1.59.0/include/boost/log/detail/i... [3]: https://github.com/boostorg/log/blob/boost-1.59.0/include/boost/log/detail/c... -- Met vriendelijke groet, With kind regards, Giel van Schijndel
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
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
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
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'. -- Met vriendelijke groet, With kind regards, Giel van Schijndel
On 28/10/15 18:03, Giel van Schijndel 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
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
On 28/10/15 17:25, Bo Persson wrote: 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/44ef1095051f389931693f5117e404ffe22b9... -- Met vriendelijke groet, With kind regards, Giel van Schijndel
participants (2)
-
Bo Persson -
Giel van Schijndel