[gdal-dev] [gdal 3.12beta1] OGRFeature::GetDefnRef now returns a const pointer

Momtchil Momtchev momtchil at momtchev.com
Thu Oct 23 04:45:10 PDT 2025


On 21/10/2025 19:08, Even Rouault wrote:
>
>> Encapsulating the object into a wrapper when returning the object to 
>> a language with automatic GC.
>>
>> If I don't do this, I will have to keep a reference to the layer or 
>> the feature. Or clone it.
>
> I see different options:
>
> 1) we revert that change. Downside: users may believe that they can 
> modify the OGRFeatureDefn* instance, which can potentially cause 
> crashes if they are OGRFeature* based on it (that was the rationale 
> for const'ifying)
>
> 2) we make OGRFeatureDefn::Reference() and Dereference() const 
> methods. But that's a clear violation of const semantics, given that 
> we have a GetRefCount() and thus the observable state is modified, so 
> not something I'd be super keen doing
>
> 3) the caller of OGRFeature::GetDefnRef() takes responsibility for 
> const_cast'ing the const pointer to a non-const pointer. For the 
> purpose of just modifying the ref counter, that's fine.


Ok, if whether its me const_casting or GDAL, this does not change the 
basic problem:

     Is incrementing the reference counter of a const object an allowed 
operation?


What happens if the Dataset or the Layer containing a returned const 
SpatialReference that has a positive reference count is destroyed?

Same goes for OGRFeatureDefn and OGRFieldDefn of course, but at the 
moment my problem is especially with OGRSpatialReference.


-- 
Momtchil Momtchev <momtchil at momtchev.com>



More information about the gdal-dev mailing list