Subject: Re: [boost] [Root Pointer] New Documentation
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-10 22:20:41
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:
>> 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
> I looked over documentation...
> 1. From what I understand it is basically reference-counting pointer
> with a "pool" that deletes pointers with dangling references. Am I
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk