Re: [Boost-bugs] [Boost C++ Libraries] #6575: copy_remaining_to and copy_some_and_update don't use allocator_traits for construction

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6575: copy_remaining_to and copy_some_and_update don't use allocator_traits for construction
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-02-19 02:57:30

#6575: copy_remaining_to and copy_some_and_update don't use allocator_traits for
construction
-------------------------------------------------+--------------------------
  Reporter:  Erik Jensen <Erik.Jensen@…>         |       Owner:  igaztanaga
      Type:  Bugs                                |      Status:  new       
 Milestone:  To Be Determined                    |   Component:  container 
   Version:  Boost 1.49.0                        |    Severity:  Problem   
Resolution:                                      |    Keywords:            
-------------------------------------------------+--------------------------

Comment (by Erik Jensen <Erik.Jensen@…>):

 Certainly copy assignment should not propagate the allocator. The problem
 with these two functions is that they construct a new object on the stack
 which they then move/copy into place. It is this initial construction that
 is the issue, not the subsequent move/copy.

 The following is an attempt of mine to fix the issue (there may well be a
 better way, but my knowledge here is limited):
 {{{
    virtual void copy_remaining_to(Iterator p)
 \
    {
 \
       if(!this->used_){
 \
          aligned_storage<sizeof(value_type),
 alignment_of<value_type>::value> v;    \
          value_type *vp = static_cast<value_type *>(static_cast<void
 *>(&v));       \
          alloc_traits::construct(a_, vp
 \
             BOOST_PP_ENUM_TRAILING(n, BOOST_CONTAINER_PP_MEMBER_FORWARD,
 _));       \
          *p = boost::move(*vp);
 \
          this->used_ = true;
 \
       }
 \
    }
 \
 }}}
 I believe this is important for a few reasons. First, there are probably
 other uses for the allocator wanting to handle object construction than
 just propagating the allocator. Second, if construct is being used for
 allocator propagation, the allocator probably doesn't have a default
 constructor, leading to a build error with the current implementation.
 Finally, even if the allocator does have a default constructor, having a
 different allocator would probably force a potentially expensive copy from
 the temporary rather that a cheap move operation, defeating an important
 reason to use emplace.

 Thanks,[[BR]]
 Erik Jensen

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