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

[Momtchil Momtchev]

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.

Just checked and it seems that a plain (non-ref) const shared_ptr can be 
copied:

#include<memory>
#include<string>
usingnamespacestd;
intfn1(constshared_ptr<string> s) {
return0;
}
intfn2(constshared_ptr<string> s) {
returnfn1(s);
}
intmain() {
constshared_ptr<string>s=make_shared<string>("s");
constshared_ptr<string>s2=s;
fn2(s);
return0;
}

This is valid even for C++98 without copy ellision.

-- 
Momtchil Momtchev<momtchil at momtchev.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251021/5ffcff1f/attachment.htm>