[geos-devel] RE: GeometryCollection interfaces & memory management

[strk]

mbdavis wrote:
> Continuing this thought, my idea is that GeometryCollections own their components, and will delete them when they themselves are deleted.  This means that the coder should *never* pass aliased Geometrys into a GeometryCollection constructor.

Is there any way to *force* this [ SHOULD NEVER ] rule ?
Isn't it safer just to make the copy for him ?
He will be left with references to 'protected' space !

If reducing copies from GEOS internal is the problem we
could provide another interface or (better) declare some
'friends' to directly access protected area.

Finally, whatever method we decide to use we should at least
make both vector and geometries of the same kind (cont or not).
Right now the vector will be copied while the geometries will not!

> Your pseudocode should read:
> 
> > > PSEUDOCODE:
> > > 	1: point = createPoint;
> > > 	2: line = createLine;
> > > 	3: polygon = createPolygon;
> > > 	4: collection1 = createCollection(point, line);
> > > 	5: collection2 = createCollection(point.clone(), polygon );  // copy point since it's already been used
> > > 	6: destroy collection1;	// no problem here
> > > 	7: destroy collection2;  // or here

My pseudocode did not go any further, but you can imagine programmer could
also want to:

 	8: destroy polygon
 	9: destroy line
     	10: destory point

Maybe after having modified the line multiple times as a DP simplification
demo ;)

> 
> This shouldn't be too onerous for users who are using the GEOS functions in fairly constrained ways (e.g. as is the case in PostGIS, I would imagine).
> 
> Norman, smart pointers look pretty tricky to understand to me.  In order for GEOS to go that route someone is going to have to take on porting the existing code base and proving that it works, is reasonable maintainable, is open, etc etc.   Also, I don't think that it really buys the user all that much.  I doubt there are very many usage patterns where it really is desired to have aliased Geometrys.  The only reason I can think of is to save space, and that's pretty much a non-issue these days, for any reasonable usage.
> 
> It seems to me that the saving grace of GEOS memory management is that the only objects which users might want to persist are Geometrys.  All other objects created by the API are temporary during method invocation.  This might offer another way to guarantee memory safety - develop a memory management layer based on sub-allocation out of an extensible pool of memory.  When a method completes the entire pool is freed.  Anyone have any opinions on whether this is a reasonable strategy?

I think smart pointer would make the code even less readable and harly
controllable.

The memory management layer could be a good idea but first of all we'll
need to decide the scope of this entire pool. Which methods will create
a new pool ? How long will these pool last ? I feel confortable with
the general assumption about Geometry-only persistence.

--strk;

> > -----Original Message-----
> > From: Martin Davis 
> > Sent: Monday, October 20, 2003 9:14 AM
> > To: GEOS Development List
> > Subject: RE: [geos-devel] GeometryCollection interfaces
> > 
> > 
> > Personally I felt that this was pretty much an issue for the 
> > programmer.  He needs to be aware that he is aliasing 
> > Geometrys when he's constructing them, and copy them as 
> > necessary.  I don't think this copying should be done 
> > internally by GEOS, since it can't know the usage pattern and 
> > so may make unecessary copies.
> > 
> > What are your ideas for coping with this?
> > 
> > Martin Davis, Senior Technical Architect
> > Vivid Solutions Inc.
> > Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
> > Phone: (250) 385 6040    Fax: (250) 385 6046
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: strk [mailto:strk at keybit.net]
> > > Sent: Sunday, October 19, 2003 3:49 AM
> > > To: geos-devel at geos.refractions.net
> > > Cc: pramsey at refractions.net
> > > Subject: [geos-devel] GeometryCollection interfaces
> > > 
> > > 
> > > When constructing geometry collections (Multi*, GeometryCollection)
> > > we will pass the constructors a vector to "component" geometries.
> > > The vector will be untouched while the pointed-to geometries will
> > > be taken on by created object. This means that you can NOT
> > > delete base geometries passed to geometry collection constructor.
> > > This also mean that you can not do something like:
> > > 
> > > PSEUDOCODE:
> > > 	1: point = createPoint;
> > > 	2: line = createLine;
> > > 	3: polygon = createPolygon;
> > > 	4: collection1 = createCollection(point, line);
> > > 	5: collection2 = createCollection(point, polygon);
> > > 	6: destroy collection1;
> > > 	7: destroy collection2;
> > > 
> > > This is because line 6 will destroy all collection1 components that
> > > is point and line. Line 7 will try to destroy components of 
> > > collection2
> > > which are point and polygon. Well: point will have been 
> > > already destroyed,
> > > segfault!
> > > 
> > > Needless to say you won't be able to use point, line, polygon 
> > > any further
> > > because you are left (after line 6) with pointer to "private" space!
> > > You have loaded weapons in your hands!
> > > 
> > > What do you think about this ? I have few proposal, but I'd 
> > > like to hear
> > > from you first.
> > > 
> > > --strk;