[gdal-dev] Regarding to the memory management in the SWIG API
even.rouault at mines-paris.org
Wed Jan 8 02:27:57 PST 2014
Le mercredi 08 janvier 2014 11:10:58, Tamas Szekeres a écrit :
> Hi Devs,
> Is that intentional that we don't call ReleaseResultset within the
> destructor of the OGR Layer object?
The OGR Layer object has generally no pointer to the datasource from which it
originates (well, at the swig level we could probably attach one), so you
cannot call ReleaseResultSet
> Actually the destructor is not even
> generated (at least for the C# API)
That must be the case of all bindings, because the OGR Layer object has no
destructor in its API. OGR C++ Layers obtained by OGRDataSource::GetLayer()
are owned by the C++ OGRDataSource and destroyed by it.
> which seems to be an improper solution
> and leads to memory leaks, definitely. However ReleaseResultset is exposed
> in the API, but it's fairly dangerous to let the user decide whether to
> call this method or not.
Yes, that's not very popular in garbage collected languages to let the user
deal with memory management...
> In my understanding the destructor of the Layer object should look
> something like the destructor of the DataSource (but calling
> ReleaseResultset instead of ReleaseDatasource).
Actually you should distinguish how the Layer object has been created : if it
comes from GetLayer() or ExecuteSQL()
> However modifying the code
> this way, may lead to a crash for the existing code which call
> ReleaseResultset directly.
Yes, that would cause breakage in all existing code. The alternative would be
that the public SWIG ReleaseResultSet() becomes a no-op and the destructor of
SWIG Layer object call OGR_DS_ReleaseResultSet() when appropriate.
> Any opinion?
> Best regards,
Geospatial professional services
More information about the gdal-dev