[Gdal-dev] Re: GetGeometryRef in scripts

Charlie Savage cfis at interserv.com
Wed Sep 21 02:11:53 EDT 2005


> I'm not sure why it matters what order things are destroyed in as
> long as you hold a reference to things till you are done with them. 

Yes, agreed.  As long as you hold the a reference to the parent object 
you are fine.

For example (feature owns geometry):

    feature = layer.get_next_feature
    geom = feature.get_geom_refn

    <do stuff with geom>

    // release top level feature
    feature = nil

The one issue could be the chaining issue that's been brought up:

geom = layer.get_next_feature.get_geom_refn

If the dynamic language decides to gc the feature on you during the 
expression then you have a problem.  But I would be surprised if any 
language actually does this - I would think you are safe within a single 
expression.  But I haven't checked.

IMHO I would vote to go down this route instead of implementing lots of 
complicated reference counting C++ wrappers.  Both because it will be 
really hard to get right, and second, if we start making copies of 
everything I worry about performance.

Charlie



> 
>>  There are a couple of ways
>> to mitigate this:  We could adopt a "no-fail" destructor strategy.  That
>> is ensure that under no circumstances will destructors being called in
>> the wrong order cause troubles.  Quite frankly I don't know how this can
>> be done.   
> 
> Perhaps you could clarify where we have problems with gc 
> languages.  I *feel* this isn't a problem, because language
> variables that reference objects should not need to do anything
> at all for objects they don't own.  So, for instance, a reference
> to a geometry that is owned by some other object does not need
> to do any work at all in it's destructor other than check it's
> "owned" flag.  
> 
> Best regards,





More information about the Gdal-dev mailing list