[gdal-dev] Can c++ types be used directly from the SWIG interfaces?

[Laurențiu Nicola]

Hi Even,

Speaking for the Rust bindings, they have two parts: one is automatically generated by parsing the header and includes almost everything (macros, inline function etc. will be problematic), and one is C++-ish, written manually, and woefully behind the GDAL functionality. Users can switch between them as needed.

Specifically for GeoTransform, we expose e.g. GDALApplyGeoTransform in the low-level bindings, and GeoTransform is an alias to an array of six floats in the high-level ones, with extra apply and invert methods somewhat hidden behind an import, which call the C functions. IsAxisAligned seems to be missing from both.

Now if SWIG could generate the high-level APIs, that would save a lot of work and especially bikeshedding, but I don't see it happening, so you don't need to worry about it.

Laurentiu

On Tue, Sep 1, 2026, at 21:02, Even Rouault via gdal-dev wrote:
> Michael,
> 
> This is likely a design decision from 20 years ago when the "new" bindings have been added. I wasn't involved, but I can imagine at least 2 reasons to prefer binding C functions rather than C++ classes:
> 
> - make sure that the bindings generated against GDAL X still run against libgdal Y where Y >= X without being rebuilt, since the C ABI is backwards compatible. But that doesn't seem to be a very realistic/common scenario
> 
> - avoid exposing to SWIG things that haven't been considered stable enough to be exposed to C
> 
> Maybe other GDAL users, such as people doing Rust or R bindings, could give us some hints if they'd be interested in binding the GDALGeoTransform class to their language. If so, making C bindings would serve everybody.
> 
> Even
> 
> Le 31/08/2026 à 21:50, Michael via gdal-dev a écrit :
>> I want to expose the GDALGeoTransform class. It doesn't have a C struct representation (like OGREnvelope) or an opaque C handle type. I could add C interfaces to  GDALGeoTransfor, but that seems absurd since GDALGeoTransfor is mostly a C++ wrapper of the C routines.
>> 
>> However, using the GDALGeoTransfor class directly from the SWIG interfaces works surprisingly well (See below). What doesn't work is the 'Apply' overloads which accept a `GDALRasterWindow` type, because SWIG can't include gdal_rasterband.h while CPL_SUPRESS_CPLUSPLUS is defined.
>> 
>> So my questions are: can I use the GDALGeoTransfor c++ class directly from SWIG and, if not, why?
>> -------------
>> 
>> %{
>> #include "gdal_geotransform.h"
>> %}
>> 
>> class GDALGeoTransform {
>> private:
>>   const double *data() const;
>>   ~GDALGeoTransform();
>> public:
>> %mutable;
>>   GDALGeoTransform();
>>   GDALGeoTransform(const double coeffs[6]);
>>   GDALGeoTransform(double xorigIn, double xscaleIn, double xrotIn, double yorigIn, double yrotIn, double yscaleIn);
>>   void Rescale(double dfXRatio, double dfYRatio);
>> %immutable;
>>   void Apply(double dfPixel, double dfLine, double *pdfGeoX, double *pdfGeoY) const;
>>   bool GetInverse(GDALGeoTransform &inverse) const;
>>   bool IsAxisAligned() const;
>> };
>> 
>> --
>> Michael Bucari
>> 
>> _______________________________________________
>> 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.
> LLMs contribute to global warming and brain rot.
> Let's guillotine them! "Ah ! ça ira, ça ira, ça ira !"
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260901/9c0f3828/attachment-0001.htm>