[geos-devel] Finding the Leak

[Martin Davis]

I don't really feel competent to comment on Mateusz' suggestion of smart 
pointers.  But in the near term, isn't the simplest solution just to 
declare that managing the Geometry associated with the PreparedGeometry 
is the responsibility of the client?  In this case the client is 
PostGIS, and I think I'm right in saying that there is an obvious, 
correct place to delete the created geometry - i.e. immediately after 
the PrepGeom is deleted.

This avoids copying, and doesn't require any fancy pointer stuff.

Or am I missing something?


Paul Ramsey wrote:
> 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
>>
>>     
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022