[geos-devel] Finding the Leak

[Paul Ramsey]

I was thinking that the blunt-force solution would be to clone the
Geometry when PreparedGeometry is constructed, rather than retaining a
reference, so we an delete the whole kit-n-kaboodle when we're done
with the PreparedGeometry.

P.

On Mon, Aug 18, 2008 at 7:15 PM, Mateusz Loskot <mateusz at loskot.net> wrote:
> 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
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>