Re: [boost] [Root Pointer] New Documentation

Subject: Re: [boost] [Root Pointer] New Documentation
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-04-10 21:58:28

On 04/11/2016 11:07 AM, Phil Bouchard wrote:
> On 04/10/2016 07:58 PM, Vladimir Batov wrote:
>> To begin with, I feel that your main argument in favor of your library
>> compared to the std::shared_ptr is that your library takes care of
>> cycles. I am personally yet to be convinced that the cycles-related
>> problem is actually as big as you make it. More so, std::shared_ptr does
>> manage cycles with weak_ptr and discipline. ;-)
>
> I haven't seen any implementation of a neural network with shared_ptr 
> yet...  Mine was done in nothing more than a month in my spare time.

I am not sure that argument can be used to justify acceptance of your 
library... or anything really :-) due to its subjectivity and lack of 
"measurability".

Secondly, I am not sure a network/graph (neural or not :-)) needs to use 
std::shared_ptr to manage memory at all. I am debugging one of them 
right now... The main reason is that the network/graph class is already 
a nodes/resources/memory manager, i.e. it takes care of nodes 
management...  memory management included.

>
>> Second, I feel that Artyom asked an excellent question which IMO
>> highlights a fundamental flaw with your library.
>
> He asked an excellent question indeed and I will answer it as soon as 
> I can.

I have not looked at the implementation but from the design description 
I suspect I know the answer. The core design decision (if I've got it 
right) is that all node_ptrs are freed when its root_ptr goes out of 
scope irrespectively of cycles or still legitimate references. Yes, it 
solves the cyclic references... but also it invalidates all other 
references.

>
>> I feel that your library does not solve the cycles problem but rather
>> replaces it with another problem.
>
> The concept of having a root_ptr can be applied to all container-like 
> classes because for example all implementations of lists have an 
> internal cyclic nodes from what I've seen.
>
> This concept can also be easily applied to cyclic graphs as well. 
> People do not use C++ for their implementation of neural network... 
> Why? Because they prefer to use a garbage collected language to handle 
> the memory given the network can be quite complex.
>
> C++ will need to handle that complexity sooner of later.

Well, I've noticed you tend to make quite grandiose statements like "50 
years wondering about GC", "People do not use" and "C++ will need". If I 
were you, I'd certainly refrain from those -- they add nothing but might 
show you in unfavorable light. Because if you and I disappear from the 
face of the earth tomorrow, the humankind, IT and C++ won't be left to 
"wonder for 50 years about" anything. Trust me.

Secondly, I work with networks/graphs. I do not use GC and C++ handles 
that "complexity" just fine. In fact, if I had to name an area which I'd 
label with the "complexity" tag, it would not be the memory management.

>
> > Namely, the problem of managing the
>> life-cycle of the memory manager (strangely called root_ptr). And IMO
>> that problem is quite serious given that all node_ptrs spawned from the
>> main root_ptr are freed (regardless of the cycles or existing
>> references) when that root_ptr is destroyed.
>
> There is a minimum of explicitness that needs to be done by the 
> programmer. 

That argument is as good for shared_ptr/weak_ptr combination as it's 
good for root_ptr/node_ptr... If I were forced to deploy one or the other.

> Because letting the entire memory being managed implicitly results in 
> slow performance like we see with Java or Javascript.

Well, we are not in Java. And from C++ perspective your statement is so 
wrong that I do not know even where to begin. :-) But that's a different 
altogether topic.

V.