[gdal-dev] Re: an advise about OGR const member function

[Frank Warmerdam]

Pan Liang wrote:
> example:
>     bool func(const OGRFeature* poFeature)
>     {
>         ...
>         // long OGRFeature::GetFID()
>         if( poFeature->GetFID()== _nFID )       return true;    //
> error C2662 in msvc2003.net
>         ...
>     }
> 
> but if long OGRFeature::GetFID() is declared as :
> long OGRFeature::GetFID() const, all is right.
> 
> such const member function modify can be applied to OGRFeatureDefn*
> OGRFeature::GetDefnRef() etc.

Pan,

I'm not sure why this went to gdal-dev-owner instead of gdal-dev or me
personally.  I've taken the liberty of bringing this back to gdal-dev.

I'm generally very leery about "const correctness" changes.  The alter
the ABI and generally cause more disruption than you might imagine.  If
we are going to do a bunch of const correctness changes they must only
occur in the development version (trunk - which will be 1.6.0 eventually)
and should only affect the C++ not C ABI.  We attempt to keep the C ABI
backward compatible to the greatest extent possible.

If you feel strongly about this matter, I would suggest you prepare an
RFC listing all the const correctness changes you would like to see made
for GDAL 1.6.0, and they can be discussed as a project and if approved
moved forward.

In the meantime, you will just need to cast away the constness of the
OGRFeature for methods such as you show above.

I do think we need to be more careful about getting const correctness
right in the first place when adding new interfaces to the library.

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    | President OSGeo, http://osgeo.org