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

[Michael]

I've explored exposing GDALGeoTransform to the C API via an opaque handle,
but the results are a net negative. All C functions which accept a double
array geoTransform would need a `2` method for the new `GDALGeoTransformH`
type, littering the API with almost useless duplicates. The one
functionality which GDALGeoTransform currently has that I would like to
access via the C API is the 2 apply methods that operate on OGREnvelope
and GDALRasterWindow. I think it makes sense to move those implementations
into new C functions: GDALApplyGeoTransformToWindow()
and GDALApplyGeoTransformToEnvelope(). Then, expose GDALRasterWindow to the
C API in the same way that OGREnvelope is exposed (by making it a struct
if CPL_SUPRESS_CPLUSPLUS).

For the SWIG bindings, I'd like to do something similar to
what Laurentiudid did in Rust: make GeoTransform an alias to an array of
six doubles and add helper methods which duplicate the functionality of
GDALGeoTransform methods.

Thank you all for the input,
Michael

On Tue, Sep 1, 2026 at 11:28 PM Chris Toney <jctoney at gmail.com> wrote:

> 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
>


-- 
Michael Bucari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260902/7255ee8a/attachment.htm>