Re: [Boost-bugs] [Boost C++ Libraries] #4044: reset_object_address with library-created objects

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4044: reset_object_address with library-created objects
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-03-27 09:19:13

#4044: reset_object_address with library-created objects
-------------------------------------------------+--------------------------
 Reporter:  Richard Hazlewood                    |       Owner:  ramey        
     Type:  Bugs                                 |      Status:  new          
Milestone:  Boost 1.43.0                         |   Component:  serialization
  Version:  Boost 1.42.0                         |    Severity:  Problem      
 Keywords:  reset_object_address heap allocated  |  
-------------------------------------------------+--------------------------

Comment(by Richard Hazlewood):

 I've certainly considered method-1, as you outline above.  Method-2 is an
 alternative I had not considered.  However, both would require large
 resstructuring of the code-base (which may be inevitable).

 The boost::function approach has a convenience (and elegance, IMO) for the
 application I am working on.

 It is only access to the default ctor of the function object that is
 getting in the way.  For example, I could copy the behaviour of the
 serialization library's auto_ptr_with_deleter just to get to
 serialization::access::construct<> friend:

 {{{
 template<class Archive>
 void serialize(Archive &ar, boost::function<Signature> & f, const unsigned
 int version){
   if (Archive::is_saving:value)
   {
     ar & *f.target<MyFunctor>();
   }
   else
   {
     // get memory space for functor
     auto_ptr_thing<MyFunctor> p = (MyFunctor*)new char[sizeof(MyFunctor)];
     // in-place construct through the friend
     serialization::access::construct<MyFunctor>(&p);
     // de-serialize
     ar & *p;
     // hand over (this does incur a copy)
     f = *p.get();
     // let p destruct, taking the memory with it
   }
 }
 }}}

 This avoids the object tracking.  I was just trying to avoid duplicating
 this inner-library behaviour by routing through its pointer serialization
 (and it would be ''cleaner''), but, the point of this trac, as soon as I
 do that I have to worry about tracking - and reset_object_address did not
 do what I expected.

 Ultimately, if the current library behaviour of reset_object_address is
 considered correct (or not appliable to this type of heap allocated
 object), then I will consider the alternatives.

 Thank you for taking the time to discuss this.

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