[Gdal-dev] Re: GetGeometryRef in scripts
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.
>> 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