Re: [Boost-bugs] [Boost C++ Libraries] #10740: Multi-level containers do not cooperate with address tracking

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #10740: Multi-level containers do not cooperate with address tracking
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-12-14 18:17:05

#10740: Multi-level containers do not cooperate with address tracking
-------------------------------------+-------------------------------------
  Reporter:  Simon Etter             |      Owner:  ramey
  <ettersi@…>                        |     Status:  closed
      Type:  Bugs                    |  Component:  serialization
 Milestone:  To Be Determined        |   Severity:  Problem
   Version:  Boost 1.56.0            |   Keywords:  Address tracking, STL
Resolution:  invalid                 |  containers
-------------------------------------+-------------------------------------

Comment (by ramey):

 Damn!

 This was probably why I implemented it the way I did originally.  When I
 made this fix, I use presumed that the the type T in vector<T> had to be
 default constructible as a requirement.  This turned out to be wrong - the
 requirement is CopyConststructable.  But it's worse, the requirements for
 c++11 are different.  In fact, the requirements vary by function so it's
 even trickier to get right.

 To get this really right the following needs to be considered:
 a) Go back to the previous method - but use move and/or swap to place the
 item in the array.  move is only available with C++11 though there is a
 boost move which works with previous versions but it may require some more
 declarations so I'm not sure it would work.
 b) use the current method and live with the new restriction.  Or possible
 use boost::has_trivial_constructor to condition which method is used.
 c) one has to be sure that it's as fast as possible.  The reason for this
 isn't performance, it's that some bonehead will (and have) made a
 "benchmark" which makes a really simple case then uses it to make a very
 broad statement that the serialization library is really slow.
 d) I would like to keep a c++03 implementation available - conditioned on
 a config flag.

 For now I'm setting this aside - but you're free to invest some effort in
 it if you want.  I'm happy to incorporate improvements from other authors.
 But note that all the above has to be addressed - not just a fix for a
 specific case.

 Robert Ramey

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