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
[email protected]
On Fri, Jan 30, 2026, 3:32 PM Daniel Baston <[email protected]> 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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
