Boost logo

Boost :

Subject: Re: [boost] [shifted_ptr] Review Request
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2011-04-05 10:39:35


Phil Bouchard wrote:
> For those who are not aware in 2008 I wrote a memory manager running in
> real-time so that heap objects are being destructed instantly. A quick
> introduction can be found here:
> https://svn.boost.org/svn/boost/sandbox/shifted_ptr/libs/smart_ptr/doc/
> ShiftedPointer.ppt

How is this "memory manager" related to the "smart pointer" reviewed in 2003?
<http://lists.boost.org/Archives/boost/2003/09/53333.php>

I reviewed the mentioned presentation, and I still don't get what "shifted_ptr" wants to be.
The very first slide says "Shifted Pointer" ... "Deterministic Memory Manager of Constant Complexity". The next slide that even mentions "shifted_ptr" is slide 17: "Shifted Pointer - Advantages", and it just enumerates some "advantages", without first stating what "shifted_ptr" really is. Slide 18 and 19 show an example source code using "shifted_ptr" and its output, but still no explanation what "shifted_ptr" wants to be.

I think I'm able to guess what slides 20-27 try to illustrate, but even this wasn't immediately obvious. (You write in the presenters notes, that a red circle means that the objects get collected and destroyed. You could also add to example 2 and 4 notes that some unreferenced nodes didn't get collected immediately, probably for good reasons.) I also read through some of your comments from the review in 2003. I often couldn't understand what you said, and wondered whether it was because I was missing some context that "the participants" knew from prior discussions. At least today, nearly nobody will know the context anymore, so you definitively have to be much more concrete, and explain the context explicitly.

> "shifted_ptr_test1" shows its versatility and simplicity while
> "t100_test1" shows a more complicated application on a neural network.
>
> I would like to request a review while I add the necessary documentation
> for a better support.

It's great if you come up with good documentation.

But I would suggest a much easier step first. Your presentation already exists, and it has many nice pictures and illustrates many points. Yet I have the impression that it still fails to convey the information that also some of the reviewers missed in 2003. Why don't we try to "review" and improve this presentation first? To be honest, I would really like to know what "shifted_ptr" is (or wants to be). As there is already a 28 page presentation and many examples, this should hopefully be a goal that can be achieved.

To get started, let me ask some questions (based on the examples):

1) Is the class template "shifted_ptr" a shared pointer? Does it provide pointer semantics?
2) Is the class template "shifted_ptr" a proxy object? Does it provide object semantics?
3) Can the class template "shifted_ptr" act as smart array? Does it provide array semantics when instantiated with an array?
4) Is "shifted_ptr" intended to mean that it is pointer to "shifted"?
5) Does "shifted" contain a refcount?
6) Does the class template "shifted_ptr" takes care of "shared ownership" (memory management)?

As a hint, this is how the semantics of "shared_ptr" are sometimes described:

"The shared_ptr class template stores a pointer, usually obtained via new. shared_ptr implements semantics of shared ownership; the last remaining owner of the pointer is responsible for destroying the object, or otherwise releasing the resources associated with the stored pointer."

If you manage to come up with a similar description for "shifted_ptr", most of the above questions would probably be obsolete.

I finally have a question out of pure curiosity (leave it unanswered if you want): "Is the memory manager part of Shifted Ptr some form of reference counting (on a suitable scale), or is it more related to region based memory management, or is it original research completely unrelated to any known memory management strategies?"

Regards,
Thomas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk