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

[strk]

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. For strong/weak pointers to work it takes a design decision.
If Martin never had to take it you'll be in trouble...

> > 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 ?
Where I left it it had no dependencies except a C++ compiler
and the standard template library.

> 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* :)
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.

--strk;