[geos-devel] Finding the Leak

[Mateusz Loskot]

Martin Davis wrote:
> That makes sense to me.  In JTS-land, PreparedGeometry was intended to
> be a "decorator" for Geometry.  (Although this is really a moot point in
> Java, since GC handles all magically....)
> 
> Under this pattern, the decorated geometry must be deleted after the PG
> is deleted, by the calling code.
>
> Next step is to try it and see!
> 
> Oh, and yes, the Geometry needs to outlive the PG...


If the requirement that Geometry (G) needs to outlive PG is strong,
then using raw pointers for linking G and PG objects is not safe
regarding resources management (memory).

I'd even rephrase the requirements above this way:
"G and PG *share* common resources and we *do*not* want to know when
this resources needs to be released (memory deallocated)"

Possible solution is to use smart pointer (like boost::shared_ptr)
idiom to track lifetime of shared resource and collect after
last client disconnects.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org