[gdal-dev] Breaking API Change

[Even Rouault]

Andrew,

we regularly do slightly forward incompatible changes in the C++ API, 
and they are documented in 
https://gdal.org/en/latest/user/migration_guide.html .

That change has the advantage of avoiding potential usage errors, in 
particular erroneous use of CSLDestroy() on the return value, which was 
possible when we returned "char **".   That way, you can distinguish 
that GetMetadata() return doesn't need to be freed, whereas methods such 
as GDALDataset::GetMetadataDomainList() or GetFileList() that return a 
"char**" do need to have their return value CSLDestroy()'ed after use

We could potentially have GetMetadata() return a CPLStringList (or a 
const CPLStringList&?) (CPLStringList is a C++ wrapper over a "char**" 
with a std::vector<> like API) or a std::vector<std::string> / const 
std::vector<std::string>&  ( returning "const CPLStringList&" would have 
the advantage that for the C API GDALGetMetadata(), we could use 
CPLStringList::List() to return a CSLConstList without involving memory 
copy)    But those signature changes would require both extensive 
changes in the drivers themselves since GetMetadata() is a virtual 
method they implement, and in calling code (only returning "const 
CPLStringList&" would allow user code to make forward compatible 
changes, but they would be more involved than just the change for 
"char**" -> "CSLConstList")

Even

Le 30/01/2026 à 23:09, Andrew Bell via gdal-dev a écrit :
>
>
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> On Fri, Jan 30, 2026, 3:32 PM Daniel Baston <dbaston at gmail.com> wrote:
>
>     Andrew,
>
>     I don't think any ship has sailed -- 3.13 will not be released for
>     several months.
>
>
> I just meant that the API has been consistent for like 30 years.
>
>
>     Is there a situation where the change to client code is more
>     involved than changing "char**" to "CSLConstList" ?
>
>
> Yep. But it still requires users to change their code for little to no 
> benefit. My general feeling is that you need a darn good reason to 
> require users to change their existing code, but others are welcome to 
> disagree.
>
> A different interface for this kind of thing would be nice. Perhaps 
> something better can be done and these functions can be deprecated? 
> I'm sure there are various options.
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260131/0bc38e23/attachment.htm>