Re: [Boost-bugs] [Boost C++ Libraries] #12243: Boost.Serialization compilation error in Visual Studio with Zc:wchar_t-

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #12243: Boost.Serialization compilation error in Visual Studio with Zc:wchar_t-
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2017-06-13 17:10:38

#12243: Boost.Serialization compilation error in Visual Studio with Zc:wchar_t-
  Reporter: anonymous | Owner: ramey
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: serialization
   Version: Boost 1.61.0 | Severity: Showstopper
Resolution: | Keywords:

Comment (by johnmaddock):

 Sorry to confuse things but there are actually 3 distinct and completely
 orthogonal configuration macros here, and it appears serialization may
 need all 3:

 BOOST_NO_INTRINSIC_WCHAR_T: Use when you are specializing a template or
 overloading a function on wchar_t '''as well as''' the other integer
 BOOST_NO_CWCHAR: Use before inclusion of <cwchar> or use of it's
 BOOST_NO_STD_WSTRING: Use before use of std::wstring. Perversely,
 presence of this macro does not mean that you cannot at least forward
 declare basic_string<wchar_t>, but you may not be able to instantiate it
 (or it's members) without linker errors unless the user has specified some
 command-line magic. Or to put it another way, you can still use
 basic_string<wchar_t> in templates that will only be instantiated when
 actually used: in which situation the user gets what they deserve ;)

 Note that the presence of one of these does not imply much if anything
 about the others - for example we have msvc with <cwchar> but wchar_t not
 a native type, while on gcc wchar_t is always a native type, even though
 the platform it's building for (early cygwin, some embedded platforms) has
 no wide character functions.

 There is one final conundrum that only Robert can decide on - if wchar_t
 is not a distinct type, and integer and character types are to be handled
 differently, what is the library supposed to do exactly when presented
 with an unsigned short? We have no way of knowing whether it's a
 character or an integer. Special treatment for wchar_t* seems sensible
 though since there is no special overload for unsigned short*.

 I'm not going to go through the whole codebase and suggest which should be
 used where (but let me know if you need help testing this specific
 configuration), but my suggestion would be:

 load/save overloaded on wchar_t* : use BOOST_NO_CWCHAR, ditto in the
 load/save overloaded on wchar_t : maybe check for both


Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-06-13 17:16:44 UTC