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.
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 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.
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. Because letting the entire memory being managed implicitly results in slow performance like we see with Java or Javascript.