Boost logo

Boost :

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at