Re: [Boost-bugs] [Boost C++ Libraries] #11245: Deserialization with private constructor works in 1.57 not in 1.58

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11245: Deserialization with private constructor works in 1.57 not in 1.58
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-05-06 12:18:27


#11245: Deserialization with private constructor works in 1.57 not in 1.58
-------------------------------+---------------------------
  Reporter: Thomas Aho | Owner: ramey
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: serialization
   Version: Boost 1.58.0 | Severity: Problem
Resolution: | Keywords:
-------------------------------+---------------------------

Comment (by Tony Lewis <tonyelewis@…>):

 Extra information...

 This problem doesn't just affect classes with private constructors; I'm
 finding it also breaks compilation for serialization of vectors of classes
 without default constructors (but with suitable `load_construct_data()`
 specializations).

 I've attached code (attachment:not_default_constructible.cpp) that
 compiles cleanly under v1.57.0:

 {{{
 g++ -std=c++1y -c -o ndc.o -isystem
 /opt/boost_1_57_0_gcc_build/include -ftemplate-backtrace-limit=0
 not_default_constructible.cpp
 clang++ -std=c++1y -stdlib=libc++ -c -o ndc.o -isystem
 /opt/boost_1_57_0_clang_build/include -ftemplate-backtrace-limit=0
 not_default_constructible.cpp
 }}}

 ...but that fails to compile under v1.58.0:

 {{{
 g++ -std=c++1y -c -o ndc.o -isystem
 /opt/boost_1_58_0_gcc_build/include -ftemplate-backtrace-limit=0
 not_default_constructible.cpp
 clang++ -std=c++1y -stdlib=libc++ -c -o ndc.o -isystem
 /opt/boost_1_58_0_clang_build/include -ftemplate-backtrace-limit=0
 not_default_constructible.cpp
 }}}

 Both GCC and Clang fail whilst compiling the call to the vector's
 `resize()` at line 90 of `boost/serialization/vector.hpp`.

 My hypothesis is as follows... The changes to `load()` in
 `boost/serialization/vector.hpp` since v1.57.0 introduce problems because
 they add code that requires the type to be default constructible. Though
 it's surrounded by an `if(detail::is_default_constructible<U>()){ [...]
 }`, I think that's insufficient to stop it getting compiled. If it's
 important to keep this separate code for default constructible types,
 perhaps some sort of traits/SFINAE/template-specialization approach is
 required?

 Many thanks to all who contribute effort to this.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/11245#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:18 UTC