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

Martin Davis mbdavis at VividSolutions.com
Mon Oct 20 12:32:14 EDT 2003


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.

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

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?


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: 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;
> > 
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at geos.refractions.net
> > http://geos.refractions.net/mailman/listinfo/geos-devel
> > 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
> 



More information about the geos-devel mailing list