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

[Tim Beckmann]

I think const correctness is important.  However, changing it doesn't 
cause me any pain ;).  (but not changing it does cause pain in the 
long-term by needing to typecast away const when it shouldn't be needed)

For backwards compatibility, you could have two versions of the affected 
methods included, one with the const declaration and another without it. 
One version could simply call the other with the correct cast.  Then at a 
major release point, the non-const version could be deleted and the 
appropriate warning issued to users.

Tim
--------------------------------------------------------------------------
Tim Beckmann               tbeckman at usgs.gov
Software Project Lead
SAIC
EROS Data Center, Sioux Falls, SD 57198
605-594-2521    Phone
605-594-6940    Fax





Frank Warmerdam <warmerdam at pobox.com>
Sent by: gdal-dev-admin at remotesensing.org
05/14/2003 07:59 AM
Please respond to gdal-dev

 
        To:     Ben Discoe <ben at vterrain.org>
        cc:     Roger James <rogerjames99 at btinternet.com>, gdal-dev 
<gdal-dev at remotesensing.org>
        Subject:        [Gdal-dev] Re: Adding const to OGR geometry classes?


Ben Discoe wrote:
> Hi Frank,
> 
> I have been forging ahead with the plan to make heavier use of the OGR
> geometry classes as replacements for the old, simple geometry classes 
the
> VTP currently uses.
> 
> This means i've been starting to use classes like OGRPolygon directly 
for my
> own storage and methods, rather than just as a means to use OGR as a 
format
> reader.
> 
> Here is one thing i've encountered.  How would you feel about adding 
'const'
> as appropriate in methods that won't modify what they're passed.
>                e.g.
> << OGRLinearRing::OGRLinearRing( OGRLinearRing * );
> 
>>>OGRLinearRing::OGRLinearRing( const OGRLinearRing * );
> 
> 
> <<    void   OGRPolygon::addRing( OGRLinearRing * );
> 
>>>   void   OGRPolygon::addRing( const OGRLinearRing * );
> 
> 
> If you have no objections, i'd be happy to make the changes and submit 
them
> to you.  I can play it conservatively, only using const where it's 
entirely
> unambiguous.

Ben,

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.  After getting burned painfully
with previous const correctness changes you suggested in 
OGRSpatialReference,
I have been hesitant to apply more.

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

I am cc:ing this to the gdal-dev list to collect other opinions on whether
const correctness changes are worth the pain.  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?

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


_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev