1. From what I understand it is basically reference-counting pointer with a "pool" that deletes pointers with dangling references. Am I right?
Hmmm - I think it's much more interesting to think in terms of what problem the library solves as opposed to how it does it.
Yes and no, considering that GC and reference counting is widely used and researched concept than if you come with a new magic bullet you need to explain how and not what do you solve. For example python provides reference counting and cycle detection in gc...
3. What happens when root_ptr is deleted and node_ptr exists? Does use of node_ptr lead to undefined behavior? If so it should be marked as big warning.
To me, the main weakness of the document is the absence of type requirements - aka concepts. Documentating these requirements goes a long way to answering questions like that above. Again, you're being held to a higher standard than many libraries already in boost.
Yes you are right but it is very basic utility library so, as it was proven the stuff like that must be documented.
From my point of view the biggest issue of shared_ptr/reference counting isn't cyclic references (that are easily broken with weak references and some smart programming) but rather the overhead of the atomic operations that cost hundreds of cycles and cache invalidation. This is BTW one of the major reasons GC is more efficient in certain scenarios.
It seems to me that this is not the focus of the library but rather feature of the implementation. It seems that this is a criticism of the submission for not addressing some other problem. It's very possible that these features are more interesting that the original purpose of the library. But I don't think that it's fair criticism of the library itself, but rather an idea for a different library.
I just provide an input. GC is very wide topic. But currently it isn't major issue from my point of view.
Run benchmarks of copying pointers as well in single core case and multiple core cases.
IMHO it is interesting concept a sort of merge between object/memory pool and shared_ptr.
LOL - I think you're mixing what the library does with how it does it.
In case of memory management both are equally important. Artyom