Boost logo

Boost :

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
>> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at