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).
For reference, the mentioned option's usage is detected in boost by this
option preventing #definition of _NATIVE_WCHAR_T_DEFINED to indicate it
did this. In boost/config/compiler/visualc.hpp there's the following code:
#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
