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