[geos-devel] Deleting PrecisionModels
Yury A. Bychkov
me at yury.ca
Mon Apr 7 20:27:42 EDT 2003
Yes, that makes sense. I'll try to change PrecisionModel to value type.
BTW, GEOS has not yet been thoroughly checked for memory leaks and other
allocation problems (even though I tried not to make such mistakes ;-)), so
there might be some more problems like this.
----- Original Message -----
From: "Martin Davis" <mbdavis at VividSolutions.com>
To: "GEOS Development List" <geos-devel at geos.refractions.net>
Cc: "Yury Bychkov (E-mail)" <ybychkov at direct.ca>
Sent: Monday, April 07, 2003 4:32 PM
Subject: RE: [geos-devel] Deleting PrecisionModels
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
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
> like Point.cpp.
> There's some major issues here, I hope that they can be easily solved.
> Lets look at some code like this:
> WKTReader *r = new WKTReader(new GeometryFactory(new
> 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
> 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
> b) delete g1;
> r, g2, and the GeometryFactory have an illegal
> since the Geometry delete method also deletes the shared
> c) delete the GeometryFactory
> This is okay since the Factory doesnt delete the
> PrecisionModel. Note - using "new GeometryFactory()" will leak a
> JTS gets away with this because of java's reference counting
> and garbage
> 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.
> geos-devel mailing list
> geos-devel at geos.refractions.net
geos-devel mailing list
geos-devel at geos.refractions.net
More information about the geos-devel