Boost logo

Boost :

Subject: Re: [boost] [Block Pointer] Update
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-03-13 18:29:38

On 12/03/2016 02:02, Phil Bouchard wrote:
> On 03/11/2016 01:31 AM, Gavin Lambert wrote:
>> On 11/03/2016 16:50, Phil Bouchard wrote:
>> I don't really understand the proxy thing, but I sense possible trouble
>> in a single API name apparently creating different behaviour depending
>> on the first parameter type, especially when the remaining parameters
>> appear to be forwarded constructor parameters. (What happens if you
>> want to construct an object that takes a proxy as a parameter?)
> The proxy ensures all sub allocations will be wiped out when it is
> destructed, cyclic or not.

So basically just an arena?

> But I guess I could define a new type like:
> struct list {
> public:
> [...]
> private:
> block_root_ptr<node> root;
> };
> Where block_root_ptr could be something like:
> template <typename T>
> struct block_root_ptr : private block_proxy, public block_ptr<T>
> {
> block_root_ptr() : block_proxy(),
> block_ptr<T>(static_cast<block_proxy &>(*this)) {}
> };
> Subsequent make_*() would follow the respective syntax. Thanks for your
> input...!

I'm not sure a new type is appropriate, since I thought part of the
point was that consumers of the pointers don't know which one is the
root, and separate arenas/proxies could end up getting merged based on
usage. It just seems to be something required at construction time only.

Also bear in mind that since people get into bad habits with passing
smart pointers by value instead of by reference, any such type has to be
slice-safe or you invite trouble. (ie. someone is going to construct a
block_root_ptr and then pass it by value as a block_ptr, possibly
destroying the original copy. In that second design, every single child
block_ptr will explode at that point.)

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