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

[Chris Toney]

Hi,
The `gdalraster` R bindings are also written manually. They implement
a ~thin layer of abstraction over the raster and vector object models,
provided as a class-based interface. These are implemented as C++
classes directly exposed to R. There is additionally a large number of
stand-alone functions for utils, VSI file system, etc., including
geotransform conversions and invert. We primarily use the C API but
there a few exceptions where C++ API is used, i.e., we're not
constrained to C API. It is more of a personal preference, and
historical habit likely motivated by ABI compatibility originally. I
don't expect we would bind a C API for GDALGeoTransform.

Thanks.

Chris

On Tue, Sep 1, 2026 at 12:31 PM Laurențiu Nicola via gdal-dev
<gdal-dev at lists.osgeo.org> wrote:
>
> 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
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev