[Gdal-dev] Filling a RasterBand with a constant value?

[Frank Warmerdam]

Marcus Barnes wrote:
> I would like to strengthen Frank's statement. Adding a new method to a
> class breaks binary and link compatibility. Therefore if a method is
> added to a class it is a major revision of the software. Not a minor or
> maintenance revision. 
> 
> This is a general principle of versioning that aims to avoid "DLL Hell"
> among other problems. Minor and Maintenance versions of software are
> required to be link compatible. So an application that compiles against
> library v1.0 will run with any version v1.x.y of that library without
> recompilation or relinking.
> 
> So unless you are prepared to change GDAL to 2.0.0 across the board I
> would look for a compatible means to achieve this fill effect.

Marcus,

I would like to add a few qualifications.

  o Adding a new non-virtual method does not have any significant
    ramifications on backwards compatibility.  The new version of the library
    can be used in the place of old versions without problems by C++ classes.

  o Add a new virtual method changes the organization of the vtable (the
    virtual method function table) for the class, and unless the new method
    happens to be added at the end, it will break binary compatibility.  The
    new library cannot be used in place of the old one for applications using
    the C++ API.

  o Adding new data members in class the application call create with new
    also breaks backward compatiblity.

  o Adding virtual methods or data members does not have any impact on
    applications using the C API.

In general the only thing that will break backward compatibility for C
applications is removing a C callable function or changing the argument list
of a C callable function.

I have come to accept tight coupling in GDAL C++ applications to the library.
The class data members, and virtual method tables change pretty much every
week in CVS.  The latest example of this was my addition of the GDALDataset
class level methods for RasterIO() on behalf of Keyhole I might add!  However,
I try to be very circumspect about changing the argument lists of existing
C functions, or of removing existing ones.  In some cases, like
GDALGetDriverShortName(), I actually retained the C entry point and
redirected it after the methodology of the C++ classes moved this info into
driver metadata.

I would also note that effectively the major version of GDAL is currently "1.1"
not "1".  I have used the prefix "1.1" ever since a few months after the first
GDAL release in 1998 or so.  This is really lame version naming on my part.

It is my intention to goto 1.2.x versions fairly soon, and at that time to
start including proper version information in the names of the installed
GDAL libraries with semantics matching what you describe (at the C but not
C++ level).  A move to 2.x would likely not happen unless I finally unify the
the GDAL and OGR APIs. I forsee no real other need for that degree of breakage
on backward compatibility.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent