Seth wrote:

To me it looks like this comprehensively refutes the purpose of the block_ptr as a ref-cycle mitigation scheme: the programmer seems to still be responsible for anticipating cycles and special casing destructors for it.

This problem can't be solved in general. When you have struct node { node_ptr<node> p_; ~node() { p_->something(); } void something(); }; and you have a cycle with two nodes pointing at each other, it's simply not possible to destroy them properly. The shared_ptr collectors with which I have experimented try to sidestep this by first zeroing all pointers that participate in a cycle, then running the destructors. So you'd need ~node() { if( p_ ) p_->something(); } See for example http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2232.html#cycles I abandoned this proposal because I could think of no way to make it work with multiple threads and weak_ptr.

On March 13, 2016 6:36:49 PM EDT, Phil Bouchard wrote:

So you have a cycle being wiped out by the proxy:

+-> a1 ---> a2 -+ | | +---------------+

1) a1.~A() will be called

2) a1.~A() will call a2.foo()

3) But a2 might have been wiped out already.

So if you try to access a member in the destructor without explicitly checking if it was destroyed already then this will lead to an undefined behavior, just like dereferencing a null pointer.

I could throw an exception when operator -> is used while a cycle is being destroyed but I don't think the overhead is worth it for this special case only.

Neither answer is great. The exception could occur during shack unwinding, so you couldn't use your pointers in very many contexts. No exception means UB, which means users have to remember a special case and thereby lose safety. I fail to see how that is better than using weak_ptr. In that case, one must always be explicit rather than remember special cases. ___ Rob (Sent from my portable computation engine)

On 15/03/2016 01:23, Phil Bouchard wrote:

On 03/14/2016 07:35 AM, Rob Stewart wrote:

...

Neither answer is great. The exception could occur during shack unwinding, so you couldn't use your pointers in very many contexts. No exception means UB, which means users have to remember a special case and thereby lose safety.

I fail to see how that is better than using weak_ptr. In that case, one must always be explicit rather than remember special cases.

It is much more complicated to use an explicit weak_ptr because you need to know where the cycle ends, etc.

What if you have a neural network? How do you define where to use weak_ptr over shared_ptr, etc.?

The basic rule for tree structures is to use shared_ptr when pointing "down" from parent to child and weak_ptr when pointing "up" from child to parent. (The above assumes that you want the whole tree to stay alive when you have a pointer to the root, which is the common case. In some cases though it's more useful to reverse the tree, such that keeping a pointer to a child keeps all its parents alive. Either way works, though not mixing the two.) For more free-form graphs it's a bit harder to define, obviously. A simple solution (albeit one that requires a bit of double handling) is to have each node only use weak_ptrs to point at each other, and store the shared_ptrs for each node in a bag or map in the graph container object. It's typically only a slight increase in housekeeping work when adding/removing nodes.

On 03/13/2016 02:52 PM, Bjorn Reese wrote:

On 03/13/2016 07:04 PM, Phil Bouchard wrote:

...

Also the documentation is outdated as proxies are now explicit but it'll give you the general idea.

Are proxies regions? (cf. your earlier reference to region-based memory management.)

Yes, it marks a region.

On 03/13/2016 05:23 PM, Phil Bouchard wrote:

On 03/13/2016 02:52 PM, Bjorn Reese wrote:

...

On 03/13/2016 07:04 PM, Phil Bouchard wrote:

...

Also the documentation is outdated as proxies are now explicit but it'll give you the general idea.

Are proxies regions? (cf. your earlier reference to region-based memory management.)

I could rename: - proxy_ptr<> -> root_ptr<> and - block_ptr<> -> leaf_ptr<>

Or perhaps: - proxy_ptr<> -> root_ptr<> and - block_ptr<> -> node_ptr<>

On 03/13/2016 05:41 PM, Vinícius dos Santos Oliveira wrote:

2016-03-13 18:38 GMT-03:00 Phil Bouchard :

...

Or perhaps:

- proxy_ptr<> -> root_ptr<> and - block_ptr<> -> node_ptr<>

Or:

proxy_ptr<> -> root_ptr<> and block_ptr<> -> child_ptr<>

Thanks but I just can't see function calls using: void foo(leaf_ptr<int> const & p); void foo(child_ptr<int> const & p); I think the following is better: void foo(node_ptr<int> const & p); Because you can still call the function using a root_ptr<>: int main() { root_ptr<int> p(new block<int>(10)); foo(p); } And a root is a node but a root cannot be a leaf or a child...

2016-03-13 19:01 GMT-03:00 Phil Bouchard :

Thanks but I just can't see function calls using:

void foo(leaf_ptr<int> const & p); void foo(child_ptr<int> const & p);

I think the following is better:

void foo(node_ptr<int> const & p);

Because you can still call the function using a root_ptr<>:

I wasn't aware of this behavior. I agree with `node` working better. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/