[Gdal-dev] Re: Adding const to OGR geometry classes?

[Ben Discoe]

Hi Frank,

> I realize this would be a good idea for a clean C++ interface.
> However, any constness changes alter the C++ signatures and this
> gives me no end of headaches from OGR uses trying to use slightly
> updated OGR shared libraries with precompiled applications using OGR.

Very sorry to hear that API changes cause(d) so much trouble for OGR; often
there are mechanisms for avoiding these problems, such as changing the name
of the DLL/SO to reflect API version; existing applications continue to work
with the previous version and don't conflict, while the API is permitted to
be developed rather than frozen in stone.

> Recently I have actually been encouraging applications to use the
> OGR C API to reduce the tie-age to a specific GDAL/OGR build.

C, eeeek! :)

> I realize it isn't clean, but
> the issue is just whether you need to cast away the constness in
> your application level code, right?

Indeed it is possible to do a lot of casting as a workaround, and if need
be, i can do it, until there comes a time when it is OK for the OGR API to
change.  In theory one could even define a whole set of subclasses for the
OGR classes, with each necessary method overridden to do the
unconst-casting, though it's icky.

-Ben