Boost C++ Libraries: Ticket #12243: Boost.Serialization compilation error in Visual Studio with Zc:wchar_t-

anonymous — Wed, 01 Jun 2016 15:50:28 GMT

I searched the boost code a bit and came to conclusion that you should use

    #ifndef BOOST_NO_CWCHAR

for functions that accept wchar_t literals.

Otherwise the function xml_woarchive_impl::save (and similar functions) won't work with wchar_t literals in Visual Studio with /Zc:wchar_t- .

The Boost.Serialization compilation error is a side effect of this oversight.

component changed; owner set

anonymous — Wed, 01 Jun 2016 16:04:38 GMT

owner set to Robert Ramey
component None → serialization

Robert Ramey — Tue, 01 Nov 2016 22:52:41 GMT

could you expand a little on this? Where should the define go? I'm getting that there is no fix called for in the serialization library itself.

Robert Ramey — Thu, 04 May 2017 20:04:19 GMT

So the actual bug is this 'ifndef'.

Why it was placed here? Most likely by mistake.

nope - removing it will result in compile errors on platforms which don't define wchar_t

according to documentation on boost.config, BOOST_NO_CWCHAR is meant to indicate that the platform doesn't have headers for <wchar.h> and <cwchar> so that's not a great choice either

And... If we remove the

remove #ifndef BOOST_NO_INTRINSIC_WCHAR_T

everything (including /Zc:wchar_t and /Zc:wchar_t- configurations) compiles fine.

I can't see how this would actually work

anonymous — Tue, 06 Jun 2017 12:32:12 GMT

I couldn't modify the bug description, so I placed additional info in the follow-up comment, so please read it.

In short, you should replace the uses of

#ifndef BOOST_NO_INTRINSIC_WCHAR_T

with

#ifndef BOOST_NO_CWCHAR

in several headers. (Othervise some functions for wchar_t will not be declared in /Zc:wchar_t- configuration.)

Such replacement would be consistent with other function declarations across boost, where type wchar_t is required (whether intrinsic of typedef'd). The macro BOOST_NO_INTRINSIC_WCHAR_T in these headers was used incorrectly, because the BOOST_NO_CWCHAR was actually meant.

The configuration /Zc:wchar_t- seems not to be properly tested in boost, as can be concluded from existence of this bug.

John Maddock — Tue, 13 Jun 2017 17:10:38 GMT

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 types. BOOST_NO_CWCHAR: Use before inclusion of <cwchar> or use of it's functions. 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 implementation. load/save overloaded on wchar_t : maybe check for both BOOST_NO_INTRINSIC_WCHAR_T and BOOST_NO_CWCHAR.

HTH.