[geos-devel] Deleting PrecisionModels

Martin Davis mbdavis at VividSolutions.com
Mon Apr 7 19:32:54 EDT 2003

Darn...  (stronger language used in non-virtual life).

I guess Precision Model should become a value type, so that each Geometry has its own copy created as an instance variable within the object.  This shouldn't cause any problem, other than taking up space.

Yury, does this make sense to you? Can you please make this change to the code?

In JTS 1.3 I've made a slight change that means that the PrecisionModel no longer needs to be identical between two Geometrys which are the arguments to a method (like relate, for instance).  We should make this change in GEOS as well.  I guess this should be sooner rather than later, given this issue. Note that if you're always just using FLOATING (as 99% of users will I suspect) this isn't an issue.

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
EMail: mbdavis at vividsolutions.com  Web: www.vividsolutions.com

> -----Original Message-----
> From: David Blasby [mailto:dblasby at refractions.net]
> Sent: Monday, April 07, 2003 2:52 PM
> To: Yury A. Bychkov; GEOS Development List
> Subject: [geos-devel] Deleting PrecisionModels
> Yury and everyone,
> I've been looking at memory management and the 
> PrecisionModel().  Take a 
> look at Geometry.cpp, GeometryFactory.cpp, WKTReader.cpp, and 
> something 
> like Point.cpp.
> There's some major issues here, I hope that they can be easily solved.
> WKTReader/GeometryFactory
>     Lets look at some code like this:
>     WKTReader *r = new WKTReader(new GeometryFactory(new 
> PrecisionModel(),-1));
>     Geometry g1 = r->read("some WKT");
>     Geometry g2 = r->read("some more WKT");
>     At this stage  the WKTReader, GeometryFactory (inside the 
> WKTReader), g1, and g2 all have references to the same 
> PrecisionModel(). 
>  If you were to:
>     a) delete r;
>             g1,g2, and the GeometryFactory now have pointers to an 
> illegal PrecisionModel.  WKTReader delete method also deletes 
> the shared 
> PrecisionModel.
>     b) delete g1;
>            r, g2, and the GeometryFactory have an illegal 
> PrecisionModel 
> since the Geometry delete method also deletes the shared 
> PrecisionModel.
>     c) delete the GeometryFactory
>             This is okay since the Factory doesnt delete the 
> PrecisionModel.  Note - using "new GeometryFactory()" will leak a 
> PrecisionModel.
> JTS gets away with this because of java's reference counting 
> and garbage 
> collection.
> The main issue is that Geometries share a common 
> PrecisionModel (via the 
> GeometryFactory).  This PrecisionModel is deleted in several places.
> One way to deal with this is to *never* delete a 
> PrecisionModel - leave 
> that up to the user.  Typically a program would look like:
> {
>     PrecisionModel *pm = new PrecisionModel(); //only ever make one!!
>         // make your WKTReader, GeometryFactories, and 
> Geometry's here 
> and always
>        // refer to the same pm.
>       // when there are no more Geometries or Factories, etc...
>     delete pm;
> }
> The user would have to be careful to never delete a PrecisionModel or 
> have the compiler auto-delete it (like at the end of function).
> Alternatively, each geometry can have its very own 
> PrecisionModel.  When 
> the Geometry is deleted, also delete the PrecisionModel.
> The GeometryFactory would have to clone its PrecisionModel 
> everytime it 
> creates a geometry.  Although this will have every Geometry 
> take up more 
> space, it would always be freed when its no longer needed.
> Comments?
> dave
> _______________________________________________
> 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