[Root Pointer] Seeking a Review Manager
Greetings, - "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years! - Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/ (I apologize for the misplaced images in the rationale) - The library itself can be found here: https://github.com/philippeb8/root_ptr/ All examples and tests compile fine with BJAM with GCC and MSVC. - Also here is a quick overview on the benchmarks: Single threaded: unique_ptr (new): 43.2705 unique_ptr (make_unique): 42.4111 shared_ptr (new): 68.9101 shared_ptr (make_shared): 46.6575 shared_ptr (allocate_shared_noinit): 31.2334 root_ptr (new): 30.3701 Multi threaded: unique_ptr (new): 42.1397 unique_ptr (make_unique): 43.4631 shared_ptr (new): 76.4543 shared_ptr (make_shared): 76.6611 shared_ptr (allocate_shared_noinit): 81.9926 root_ptr (new): 66.3417 - An example of its usage can be seen here: https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp We can see in the aforementioned link that outputting part of a complex graph, cyclic or not, can be done in the following simple way: cout << "Mind dump:" << endl; cout << * t100 << endl; cout << "Searching for: \"einstein\"" << endl; if (node_ptr<neuron_base> p = t100->search("einstein")) cout << p->sort().unique() << endl; cout << "Searching for: \"graviton\"" << endl; if (node_ptr<neuron_base> p = t100->search("graviton")) cout << p->sort().unique() << endl; Sincerely yours, -Phil
On 04/01/2016 01:25 AM, Phil Bouchard wrote:
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
(I apologize for the misplaced images in the rationale)
Ok I just centered the images manually: http://philippeb8.github.io/root_ptr/root_ptr/rationale.html Sorry for the trouble.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 01 April 2016 23:59 To: boost@lists.boost.org Subject: Re: [boost] [Root Pointer] Seeking a Review Manager
On 04/01/2016 01:25 AM, Phil Bouchard wrote:
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
(I apologize for the misplaced images in the rationale)
Ok I just centered the images manually: http://philippeb8.github.io/root_ptr/root_ptr/rationale.html
Sorry for the trouble.
Thanks. It should be possible (normal) for this to happen, so it might be nice to find a proper solution too. Paul
On 4/1/2016 1:25 AM, Phil Bouchard wrote:
Greetings,
- "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years!
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
I have no idea from the documentation why I should use root_ptr, what its purpose is, and when I should use it. Code examples are not an explanation of a library. I wish I could repeat that 1 million times without anybody feeling insulted. Here is the explanation I get of root_pointer from your library: "Root Pointer is a memory manager on top of reference counting and is also able to detect outright unreferenced cyclic blocks of memory." That's it ! Literally ! Honestly, do you really expect anyone to be interested in what you have done if that is the entire explanation for everything in your library ? I realize you have a tutorial but what good would that do me if I have no idea what 'root_pointer', 'make_root', 'node_ptr', and 'make_node' has to do with anything ? Of course I can ask a ton of questions but why would I want to do that if your doc doesn't tell me anything. My suggestion is to write documentation which seeks to explain the why, what, and when of what you have created.
(I apologize for the misplaced images in the rationale)
- The library itself can be found here: https://github.com/philippeb8/root_ptr/
All examples and tests compile fine with BJAM with GCC and MSVC.
- Also here is a quick overview on the benchmarks:
Single threaded: unique_ptr (new): 43.2705 unique_ptr (make_unique): 42.4111 shared_ptr (new): 68.9101 shared_ptr (make_shared): 46.6575 shared_ptr (allocate_shared_noinit): 31.2334 root_ptr (new): 30.3701
Multi threaded: unique_ptr (new): 42.1397 unique_ptr (make_unique): 43.4631 shared_ptr (new): 76.4543 shared_ptr (make_shared): 76.6611 shared_ptr (allocate_shared_noinit): 81.9926 root_ptr (new): 66.3417
- An example of its usage can be seen here:
https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp
We can see in the aforementioned link that outputting part of a complex graph, cyclic or not, can be done in the following simple way:
cout << "Mind dump:" << endl; cout << * t100 << endl;
cout << "Searching for: \"einstein\"" << endl; if (node_ptr<neuron_base> p = t100->search("einstein")) cout << p->sort().unique() << endl;
cout << "Searching for: \"graviton\"" << endl; if (node_ptr<neuron_base> p = t100->search("graviton")) cout << p->sort().unique() << endl;
Sincerely yours, -Phil
On 04/01/2016 07:32 PM, Edward Diener wrote:
I realize you have a tutorial but what good would that do me if I have no idea what 'root_pointer', 'make_root', 'node_ptr', and 'make_node' has to do with anything ? Of course I can ask a ton of questions but why would I want to do that if your doc doesn't tell me anything.
My suggestion is to write documentation which seeks to explain the why, what, and when of what you have created.
Thanks for the clarifications.
Edward Diener wrote:
I have no idea from the documentation why I should use root_ptr, what its purpose is, and when I should use it.
And specifically, when one should use root_ptr and when node_ptr, and what happens when one mistakenly uses root_ptr instead of node_ptr and vice versa.
On 04/02/2016 11:28 AM, Peter Dimov wrote:
Edward Diener wrote:
I have no idea from the documentation why I should use root_ptr, what its purpose is, and when I should use it.
And specifically, when one should use root_ptr and when node_ptr, and what happens when one mistakenly uses root_ptr instead of node_ptr and vice versa.
You will most likely have compile errors.
On 04/01/2016 07:32 PM, Edward Diener wrote:
I realize you have a tutorial but what good would that do me if I have no idea what 'root_pointer', 'make_root', 'node_ptr', and 'make_node' has to do with anything ? Of course I can ask a ton of questions but why would I want to do that if your doc doesn't tell me anything.
My suggestion is to write documentation which seeks to explain the why, what, and when of what you have created.
I added better pitch in this introduction: http://philippeb8.github.io/root_ptr/root_ptr/intro.html I even added a pretty benchmark graph which compares it to other pointers. I still need to add more text to the tutorial...
On 4/3/2016 8:13 PM, Phil Bouchard wrote:
On 04/01/2016 07:32 PM, Edward Diener wrote:
I realize you have a tutorial but what good would that do me if I have no idea what 'root_pointer', 'make_root', 'node_ptr', and 'make_node' has to do with anything ? Of course I can ask a ton of questions but why would I want to do that if your doc doesn't tell me anything.
My suggestion is to write documentation which seeks to explain the why, what, and when of what you have created.
I added better pitch in this introduction: http://philippeb8.github.io/root_ptr/root_ptr/intro.html
I even added a pretty benchmark graph which compares it to other pointers.
I still need to add more text to the tutorial...
I still am not getting what root_ptr<someType> is. Is it a replacement for shared_ptr ? What is node_ptr<someType> ? How does a root_ptr relate to a node_ptr ? Can there be numerous root_ptrs and node_ptrs for any given 'someType' ? What root_ptr and node_ptr syntax solves cyclic dependencies and how does this work ? These are some of the basic questions introductions and/or overviews should be explaining to prosepctive users of your library, preferably with good examples illustrating the explanations. You know these things but I do not see how you can expect others to know them unless you are willing to explain them in your doc using understandable paragraphs and sentences that communicate what you know.
On 04/03/2016 08:32 PM, Edward Diener wrote:
I still am not getting what root_ptr<someType> is. Is it a replacement for shared_ptr ?
There is no performance loss in using root_ptr/node_ptr over shared_ptr so therefore yes it is a replacement for shared_ptr/weak_ptr.
What is node_ptr<someType> ? How does a root_ptr relate to a node_ptr ?
root_ptr has a 1 to many relationship with node_ptr which means only 1 root_ptr should be used to refer to multiple node_ptrs. Just like: - a container (1 root with multiple nodes) or - the implementation of a webpage in C++ (1 root per page with mutliple HTML elements)
Can there be numerous root_ptrs and node_ptrs for any given 'someType' ?
Yes a class can have multiple roots to some instantiations of the class and each instantiation can have numerous number of node_ptrs contained within.
What root_ptr and node_ptr syntax solves cyclic dependencies and how does this work ?
I'll document that.
These are some of the basic questions introductions and/or overviews should be explaining to prosepctive users of your library, preferably with good examples illustrating the explanations. You know these things but I do not see how you can expect others to know them unless you are willing to explain them in your doc using understandable paragraphs and sentences that communicate what you know.
Thanks for your questions, it helps me a lot improving the documentation.
On April 3, 2016 8:53:34 PM EDT, Phil Bouchard <philippeb8@gmail.com> wrote:
On 04/03/2016 08:32 PM, Edward Diener wrote:
I still am not getting what root_ptr<someType> is. Is it a replacement for shared_ptr ?
There is no performance loss in using root_ptr/node_ptr over shared_ptr so therefore yes it is a replacement for shared_ptr/weak_ptr.
That isn't quite an answer to his question. If I understand you correctly, the point of your library is to provide a means to manage groups of related memory allocations using a root_pointer. Each related memory allocation is, I presume, a node_pointer created from, or attached to, one root_pointer. Because node_ptrs are grouped and owned by a root_ptr, they are (can be?) destroyed, as a group, when the corresponding root_ptr is destroyed, regardless of cycles. That doing so suffers no performance loss relative to shared_ptr is a bonus, not a reason.
What is node_ptr<someType> ? How does a root_ptr relate to a node_ptr ?
root_ptr has a 1 to many relationship with node_ptr which means only 1 root_ptr should be used to refer to multiple node_ptrs. Just like: - a container (1 root with multiple nodes) or - the implementation of a webpage in C++ (1 root per page with mutliple HTML elements)
Did I get the relationship correct above?
Can there be numerous root_ptrs and node_ptrs for any given 'someType' ?
Yes a class can have multiple roots to some instantiations of the class and each instantiation can have numerous number of node_ptrs contained within.
Knowing the purpose of each, add I described them above, would have answered that question.
What root_ptr and node_ptr syntax solves cyclic dependencies and how does this work ?
I'll document that.
I answered that on one paragraph above, didn't I? HTH ___ Rob (Sent from my portable computation engine)
On 04/04/2016 04:27 AM, Rob Stewart wrote:
That isn't quite an answer to his question. If I understand you correctly, the point of your library is to provide a means to manage groups of related memory allocations using a root_pointer. Each related memory allocation is, I presume, a node_pointer created from, or attached to, one root_pointer. Because node_ptrs are grouped and owned by a root_ptr, they are (can be?) destroyed, as a group, when the corresponding root_ptr is destroyed, regardless of cycles.
That doing so suffers no performance loss relative to shared_ptr is a bonus, not a reason.
[...]
I answered that on one paragraph above, didn't I?
Thanks Rob, that is a much better answer.
On 04/04/2016 04:27 AM, Rob Stewart wrote:
On April 3, 2016 8:53:34 PM EDT, Phil Bouchard <philippeb8@gmail.com> wrote:
On 04/03/2016 08:32 PM, Edward Diener wrote:
I still am not getting what root_ptr<someType> is. Is it a replacement for shared_ptr ?
There is no performance loss in using root_ptr/node_ptr over shared_ptr so therefore yes it is a replacement for shared_ptr/weak_ptr.
That isn't quite an answer to his question. If I understand you correctly, the point of your library is to provide a means to manage groups of related memory allocations using a root_pointer. Each related memory allocation is, I presume, a node_pointer created from, or attached to, one root_pointer. Because node_ptrs are grouped and owned by a root_ptr, they are (can be?) destroyed, as a group, when the corresponding root_ptr is destroyed, regardless of cycles.
I adapted the text here: http://philippeb8.github.io/root_ptr/root_ptr/intro.html#root_ptr.intro.root... And I added important notes and a pitfall to the tutorial: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html There is not much to add to the 'basic' section of the tutorial because if you wrongly use make_root and make_node then you will get compile errors.
On 04/05/2016 10:09 PM, Phil Bouchard wrote:
On 04/04/2016 04:27 AM, Rob Stewart wrote:
On April 3, 2016 8:53:34 PM EDT, Phil Bouchard <philippeb8@gmail.com> wrote:
On 04/03/2016 08:32 PM, Edward Diener wrote:
I still am not getting what root_ptr<someType> is. Is it a replacement for shared_ptr ?
There is no performance loss in using root_ptr/node_ptr over shared_ptr so therefore yes it is a replacement for shared_ptr/weak_ptr.
That isn't quite an answer to his question. If I understand you correctly, the point of your library is to provide a means to manage groups of related memory allocations using a root_pointer. Each related memory allocation is, I presume, a node_pointer created from, or attached to, one root_pointer. Because node_ptrs are grouped and owned by a root_ptr, they are (can be?) destroyed, as a group, when the corresponding root_ptr is destroyed, regardless of cycles.
I adapted the text here: http://philippeb8.github.io/root_ptr/root_ptr/intro.html#root_ptr.intro.root...
And I added important notes and a pitfall to the tutorial: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html
I was confused by this part of the tutorial: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html#root_ptr.tutoria... because I didn't see where the function bar was defined even though it is used. -regards, Larry
On 04/06/2016 08:08 AM, Larry Evans wrote:
On 04/05/2016 10:09 PM, Phil Bouchard wrote:
And I added important notes and a pitfall to the tutorial: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html
I was confused by this part of the tutorial:
http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html#root_ptr.tutoria...
because I didn't see where the function bar was defined even though it is used.
Thanks, I this function slipped through the cracks. I'll regenerate the docs tonight.
On 04/06/2016 08:08 AM, Larry Evans wrote:
On 04/05/2016 10:09 PM, Phil Bouchard wrote:
I adapted the text here: http://philippeb8.github.io/root_ptr/root_ptr/intro.html#root_ptr.intro.root...
And I added important notes and a pitfall to the tutorial: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html
I was confused by this part of the tutorial:
http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html#root_ptr.tutoria...
because I didn't see where the function bar was defined even though it is used.
I just beefed up the tutorial by explaining the example of a cyclic list and I fixed the other errors: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html Note that I didn't fix the dead links yet but please let me know if the tutorial is now acceptable. Thanks a lot!
On 04/07/2016 12:12 AM, Phil Bouchard wrote:
On 04/06/2016 08:08 AM, Larry Evans wrote:
On 04/05/2016 10:09 PM, Phil Bouchard wrote:
I adapted the text here: http://philippeb8.github.io/root_ptr/root_ptr/intro.html#root_ptr.intro.root...
And I added important notes and a pitfall to the tutorial: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html
I was confused by this part of the tutorial:
http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html#root_ptr.tutoria...
because I didn't see where the function bar was defined even though it is used.
I just beefed up the tutorial by explaining the example of a cyclic list and I fixed the other errors: http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html
... And I just added an 'intermix' section to see the behavior of using the wrong 'make' functions (to correctly answer Peter Dimov's question): http://philippeb8.github.io/root_ptr/root_ptr/tutorial.html#root_ptr.tutoria...
On 04/01/2016 12:25 AM, Phil Bouchard wrote:
Greetings,
- "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years!
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
The page: http://philippeb8.github.io/root_ptr/root_ptr/howtouse.html contains the sentence: The information given is derived from Doxygen-syntax comments in the include files, mainly root_ptr.hpp. with the link, _root_ptr.hpp_, which, when clicked, results in: 404 File not found If there's some way to check the links in the docs, it would be a good idea to use it. -regards, Larry
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Larry Evans Sent: 02 April 2016 13:59 To: boost@lists.boost.org Subject: Re: [boost] [Root Pointer] Seeking a Review Manager
On 04/01/2016 12:25 AM, Phil Bouchard wrote:
Greetings,
- "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years!
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
The page:
http://philippeb8.github.io/root_ptr/root_ptr/howtouse.html
contains the sentence:
The information given is derived from Doxygen-syntax comments in the include files, mainly root_ptr.hpp.
with the link, _root_ptr.hpp_, which, when clicked, results in:
404
File not found
If there's some way to check the links in the docs, it would be a good idea to use it.
That's disappointing as I've run the Boost inspect tool that should check for all missing links (and it said all was well), but I'm sure it is a mistake by me and I'll try to correct it. (At least you've done better than me - when I clock on the link I get only "GitHub Pages is temporarily down for maintenance."!) Meanwhile, I'm hope you can manage without this root_ptr.hpp link. Paul PS Providing documentation for a library under discussion isn't as easy as for a finished library. There is no 'right' place to put the documentation, as normally Boost documentation is a separate item.
On 04/01/2016 12:25 AM, Phil Bouchard wrote:
Greetings,
- "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years!
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
(I apologize for the misplaced images in the rationale)
Hi Phil, I've trying to understand the role of node_proxy. I went to: http://philippeb8.github.io/root_ptr/index.html then to: http://philippeb8.github.io/root_ptr/boost/node_proxy.html which contains: -{--cut here-- void unify(node_proxy const & p) const; Unification with a new node_proxy . Parameters: p New node_proxy to unify with. -}--cut here-- However, neither "unify" or "Unification" were links to their definitions. The index here: http://philippeb8.github.io/root_ptr/root_ptr/indexes/s01.html had no entries starting with "unif". I think there should at least be a definition of this term somewhere with an entry in the index linking to this definition so that people like me won't have to guess what it means. -regards, Larry
On 04/03/2016 08:45 AM, Larry Evans wrote:
On 04/01/2016 12:25 AM, Phil Bouchard wrote:
Greetings,
- "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years!
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
(I apologize for the misplaced images in the rationale)
Hi Phil,
I've trying to understand the role of node_proxy. I went to:
http://philippeb8.github.io/root_ptr/index.html
then to:
http://philippeb8.github.io/root_ptr/boost/node_proxy.html
which contains:
-{--cut here--
void unify(node_proxy const & p) const;
Unification with a new node_proxy .
Parameters:
p
New node_proxy to unify with.
-}--cut here--
However, neither "unify" or "Unification" were links to their definitions. The index here:
http://philippeb8.github.io/root_ptr/root_ptr/indexes/s01.html
had no entries starting with "unif". I think there should at least be a definition of this term somewhere with an entry in the index linking to this definition so that people like me won't have to guess what it means.
Unify is somewhat clarified by: http://philippeb8.github.io/root_ptr/root_ptr/rationale.html#root_ptr.ration... But that raises another question. The pair of side-by-side diagrams suggest that when the lower non-inherited node_ptr acquires a pointer to the upper non-inherited node_ptr, then the "corresponding" node_proxy's likewise acquire similar pointers. Now what happens when the direction is reversed? Is there then a cycle between the node_proxy's? BTW, it would also help if the root_ptr box on top of both a node_proxy and node_ptr box signifies that the subboxes are contained in the single root_ptr box. Only by looking at the code here: https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/r... was I sure this is what was meant. -regards, Larry
-regards, Larry
On 04/03/2016 11:15 AM, Larry Evans wrote:
Unify is somewhat clarified by:
http://philippeb8.github.io/root_ptr/root_ptr/rationale.html#root_ptr.ration...
But that raises another question. The pair of side-by-side diagrams suggest that when the lower non-inherited node_ptr acquires a pointer to the upper non-inherited node_ptr, then the "corresponding" node_proxy's likewise acquire similar pointers. Now what happens when the direction is reversed? Is there then a cycle between the node_proxy's?
Good question. There can be no cycle between node_proxy's because it uses an intrusive list. You can rearrange intrusive list elements however you want and you will never have a cycle.
BTW, it would also help if the root_ptr box on top of both a node_proxy and node_ptr box signifies that the subboxes are contained in the single root_ptr box. Only by looking at the code here:
https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/r...
was I sure this is what was meant.
I'll add a bold box around the root_ptrs. Thanks for the notice.
On 04/03/2016 01:15 PM, Phil Bouchard wrote:
On 04/03/2016 11:15 AM, Larry Evans wrote:
Unify is somewhat clarified by:
http://philippeb8.github.io/root_ptr/root_ptr/rationale.html#root_ptr.ration...
But that raises another question. The pair of side-by-side diagrams suggest that when the lower non-inherited node_ptr acquires a pointer to the upper non-inherited node_ptr, then the "corresponding" node_proxy's likewise acquire similar pointers. Now what happens when the direction is reversed? Is there then a cycle between the node_proxy's?
Good question. There can be no cycle between node_proxy's because it uses an intrusive list. You can rearrange intrusive list elements however you want and you will never have a cycle.
Could you please explain how an intrusive list prevents cycles. I'm probably misinterpreting what the arrow means from the lower node_proxy to the upper node_proxy. I was interpreting that to mean that node_proxy contained some node_proxy* member variable. However, looking at the code here: https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/r... and searching for node_proxy, I see no such member variable pointer. Could you further explain the meaning of the arrow in that #root_ptr.rationale.union diagram? -regards, Larry
On 04/04/2016 01:48 PM, Larry Evans wrote:
Could you please explain how an intrusive list prevents cycles.
Wherever you want to insert an element inside an intrusive_list, it will automatically reorganize the pointers to the previous node and to the next node so that the former references are lost and the new ones are created. You can have a cycle if former references are destroyed first. But I might confuse you even more by trying to explain this extra-curriculum subject.
I'm probably misinterpreting what the arrow means from the lower node_proxy to the upper node_proxy. I was interpreting that to mean that node_proxy contained some node_proxy* member variable. However, looking at the code here:
https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/r...
and searching for node_proxy, I see no such member variable pointer.
So when a node_proxy is unified with another one it enlists the new node_proxy with the following tag: mutable smart_ptr::detail::intrusive_list::node proxy_tag_; You can see here that the way to iterate through all node_proxies unified together is done the following way: using namespace smart_ptr::detail; for (intrusive_list::iterator<node_proxy, &node_proxy::proxy_tag_> i(&proxy_tag_);;) { ... if (++ i == intrusive_list::iterator<node_proxy, &node_proxy::proxy_tag_>(&proxy_tag_)) break; } For the record, the list of allocated nodes associated to a specific node_proxy is stored in the following intrusive list: mutable smart_ptr::detail::intrusive_list node_list_;
Could you further explain the meaning of the arrow in that #root_ptr.rationale.union diagram?
Once again, when node_proxies are unified then it will use node_proxy::proxy_tag_ to link the node_proxies altogether.
On 04/01/2016 12:25 AM, Phil Bouchard wrote:
Greetings,
- "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years!
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
Judging just from: http://philippeb8.github.io/root_ptr/root_ptr/rationale.html I would guess a root_ptr *must* be on the stack. However, I didn't find anything in the following: https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/r... http://philippeb8.github.io/root_ptr/header/boost/smart_ptr/root_ptr_hpp.htm... to support this. Could you please clarify? -regards, Larry
On 04/03/2016 12:31 PM, Larry Evans wrote:
On 04/01/2016 12:25 AM, Phil Bouchard wrote:
Greetings,
- "Root Pointer" is an alternative to the long unsolved problem of garbage collectors which lasted for more than 70 years!
- Thanks to Paul A. Bristow for his help on the generation of the documentation which is now available at the following link: http://philippeb8.github.io/root_ptr/
Judging just from:
http://philippeb8.github.io/root_ptr/root_ptr/rationale.html
I would guess a root_ptr *must* be on the stack. However, I didn't find anything in the following:
https://github.com/philippeb8/root_ptr/blob/master/include/boost/smart_ptr/r...
http://philippeb8.github.io/root_ptr/header/boost/smart_ptr/root_ptr_hpp.htm...
to support this.
Could you please clarify?
No root_ptr doesn't necessarily need to be on the stack; it can be a member of a container class allocated on the heap for example. So a root_ptr will most likely be either allocated on the stack, the data segment or a class member allocated on the heap. It is a "root" and once destroyed all associated node_ptr are guaranteed to be wiped out as well.
participants (6)
-
Edward Diener -
Larry Evans -
Paul A. Bristow -
Peter Dimov -
Phil Bouchard -
Rob Stewart