$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [block_ptr] Request for a review manager
From: Peter Dimov (lists_at_[hidden])
Date: 2016-02-09 08:58:57
Gavin Lambert wrote:
> This is probably not the best example of the case, but it's at least one 
> that's convenient to hand.
>
> Consider 
> http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/http/server/connection.cpp.
Reading rationale.html, it says
"If it is found to be living on the heap then a more complicated mechanism 
is involved to track the last memory block that was allocated in the same 
thread, find its address and stack up the set it will be part of until the 
first block_ptr<T> found on the stack is or data segment is initialized, 
where the new set counter will be shared with all of the newly allocated 
blocks of memory referencing each other."
so it looks like other, simpler examples, could also pose problems. 
Something like
    vector<block_ptr<X>> v;
    v.reserve( 5 );
    // do something that allocates from the heap
    v.emplace_back( new X );
The last line constructs a block_ptr<X> inside the vector's allocated 
memory, which is on the heap. So the block_ptr goes looking for a previous 
heap allocation and finds some random one.