[geos-devel] Unclear objects lifetime and ownership issues in Monotone Chain components

[Mateusz Loskot]

strk wrote:
> On Wed, Sep 24, 2008 at 08:30:13PM +0200, Mateusz Loskot wrote:
>> strk wrote:
>
>>> As long as you're sure no circular references exist, shared_ptr
>>> wuold be fine.
>>
>> I should precise I mean shared_ptr + weak_ptr. These two together solve
>> circular references issue.
>>
>>> But the point is if we GEOS needs to directly
>>> map JTS algorithms, they are based on a conservativ
>>> garbage collector.
>>
>> I can't answer this. However, I suppose it would be better if GEOS
>> implements the same algorithms as JTS does but not follows JTS
>> implementation line-by-line.
>
> Memory management is part of the algorithm, not an implementation
> detail.

It's a part of algorithm requirements and assertions, but algorithm should
not assert use of any low-level techniques to achieve them.
If an algorithm requires circular references, that's OK but it doesn't say
specifically what tools must be used with particular programming language.

AFAIU and AFAIS, GEOS does not use any tools to solve memory
management with circulars.

> For strong/weak pointers to work it takes a design decision.

You are perfectly right and that's the very reason I've started this
discussion (see my comment [1]: I think I've stuck :-)).

[1] http://trac.osgeo.org/geos/ticket/207#comment:4

> If Martin never had to take it you'll be in trouble...

Exactly! And this is seriously my concern too.
Simply, I can't see how to solve current state.

The only solution I can imagine is to take JTS algorithms, one by one,
re-analyse them and re-implement (sometimes re-design a little) having all
these issues in mind. So, final implementation fulfills requirements of
Martin's algorithms as well as fits well into conditions of C++.

AFAIR, we've talked about these kind of problems in GEOS a few times
but no one is brave enough to apply discussed ideas to the code.
Everybody is able to imagine it would require a lot of work.

>> > GCJ uses the bohem one, and is very nice.
>>
>> Bohem can solve some/many problems, but it's not native C++ and
>> portable option, it's yet another dependencies (a big one), etc.
>> I don't think it would meet users' needs and expectations ;-)
>
> 'yet another' ? Isn't GEOS depencencies-free anymore ?

C and C++ standard libraries?

You're right. I'm just still talking "Boost" to myself ;-)

> Where I left it it had no dependencies except a C++ compiler
> and the standard template library.

Nothing has changed, AFAIK.

>> Smart pointers would do solve this problem easier with
>> less complex solution. Although, I'm afraid it would require a lot of
>> work.
>
> Bohem will likely require lot of work too...
> It's fun for me to talk about these issues *now* :)

Lucky you ;-)

> You can tell why I tried manual management always so far.
>
> The most effective way was usually kind of "pools".
> Basically, you use containers of things to delete at the
> end of the operations (every operation is a class anyway).
> It usually did fine.

Generally, true but number of issues come to my mind:
Those pools are not documented.
There is no way to learn where are start and end points of operations and
algorithms, unless you read the code from start to the end.
Memory and time boundaries of operations are not documented.
So, tracking objects ownership and flows is very hard.
How do we know all users of given pool in given time (without reading the
whole codebase).
...

Best regards,
-- 
Mateusz Loskot
http://mateusz.loskot.net