Re: [boost] [Block Pointer] Update

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.)