On 4/10/16 10:01 AM, Artyom Beilis wrote:
- I beefed up the tutorial in the following documentation and now it covers everything I know about it: http://philippeb8.github.io/root_ptr/
This is one of the most important subject in computer science and I would be surprised to see no manager interested to supervise the submission of Root Pointer.
I looked over documentation...
Questions:
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.
2. What I thread safety assumptions on this library? i.e. does it use atomic operations to handle reference counters?
These are implementation issues. Not uninteresting but not the crux of the library. Not a bad idea to mention in the documentation
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.
I want to add a small thing.
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.
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.
I think that due to the simple fact that it is so basic library, before you even try to get to a formal review you need:
(a) Rewrite documentation making it very clear what every thing does including something that look trivial to you as copy constructor: restrictions, relationships, behavior what it does etc.
I think that adding Type requirements would address this very clearly.
(b) If it is your own design/research of concept say it explicitly, otherwise provide references to books, research papers that discuss root pointer algorithms
We should all be doing this. But in this case, I didn't the idea that this is promoted as some new revolutionary algorithm but rather and implementation of a simple idea - a smart pointer which handles cycles without leaking memory. Maybe a better name would help - leakproof_pointer.
(c) Describe the algorithm in much wider manner including better examples, values of reference counters etc.
Given they above, I'm not convinced that is all that interesting.
(d) Provide much wider beginner tutorial with samples
I'm thinking that this is the implementation of a simple idea to solve a specific problem. Unless I'm getting this wrong, I don't think it needs more than one tutorial example.
It looks interesting but for something that basic documentation isn't even 1/2 ready.
It's certainly no worse that most other documentation for libraries at this stage in the process.
My $0.02
Artyom Beilis
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost