Boost logo

Boost :

Subject: Re: [boost] [Root Pointer] New Documentation
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-04-10 21:07:03


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.


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