[shifted_ptr] Status
Greetings: More than a year ago I have submitted a quite stable version of the shifted_ptr memory manager. I am not aware of the level of understanding of it but I am planning writing more documentation, helping introducing it quicker. For now there is a quick presentation which can be found at: http://svn.boost.org/svn/boost/sandbox/shifted_ptr/libs/smart_ptr/doc/Shifte... As far as I am concerned, I stepped into astrophysics and I wrote a book called "Finite Relativism" reengineering the whole relativity theory with standard calculus. This is out of topic for this list but I need writing a complex simulator so I will post on "user". Thank you, -Phil
Phil Bouchard wrote:
More than a year ago I have submitted a quite stable version of the shifted_ptr memory manager. I am not aware of the level of understanding of it but I am planning writing more documentation, helping introducing it quicker. For now there is a quick presentation which can be found at: http://svn.boost.org/svn/boost/sandbox/shifted_ptr/libs/smart_ptr/doc/Shifte...
So basically you're saying you invented a new garbage collecting scheme that handles cyclic references and that doesn't have some of the problems of mark and sweep. A high-level explanation of how the scheme works, its semantics, and performance considerations would be useful. I see you're calling destructors, which you probably shouldn't. Indeed, the fact you support cyclic references means that there is no order in which to call the destructors to satisfy that every other object an object references is alive in its destructor. This is the reason why not supporting cyclic references is actually a good thing, since otherwise the scheme is only applicable to PODs.
"Mathias Gaunard" <mathias.gaunard@ens-lyon.org> wrote in message news:h6jj2p$d46$1@ger.gmane.org...
So basically you're saying you invented a new garbage collecting scheme that handles cyclic references and that doesn't have some of the problems of mark and sweep.
Indeed but I call it a "real-time object destructor" because, as its name stands, the destruction is immediate and not postponed.
A high-level explanation of how the scheme works, its semantics, and performance considerations would be useful.
The benchmarks aren't present in the repository but it is actually twice as fast when object are repeateadly allocated and deallocated.
I see you're calling destructors, which you probably shouldn't. Indeed, the fact you support cyclic references means that there is no order in which to call the destructors to satisfy that every other object an object references is alive in its destructor. This is the reason why not supporting cyclic references is actually a good thing, since otherwise the scheme is only applicable to PODs.
I think the order of destruction is the exact opposite of their construction when the objects have no relation between each other, just like a stack. Thanks for the specifications, I will document the layers. Regards, -Phil
participants (2)
-
Mathias Gaunard -
Phil Bouchard