PreparedGeometry and const

[Sandro Santilli]

On Thu, Aug 08, 2024 at 03:25:33PM -0700, Paul Ramsey wrote:
> Have a gander at the PreparedGeometry.h file.
> It asserts that all the prepared predicates are const.
> Have a gander at the implementation of, say, PreparedPolygon::intersects()
> It naturally also declares itself to be const, but it calls the “static” function PreparedPolygonIntersects::intersects(this, g):
> Which in turn instantiates a PreparedPolygonIntersects object, and then calls back to prepPoly->getIntersectionFinder(), which lazily creates a FastSegmentSetIntersectionFinder on the PreparedPolygon… which makes the whole thing not actually const, the state of the system is changing.
> I assume this is managed by the strange two-step of the const function calling the static function that in turn reaches back and mutates its caller. 
> 
> I wouldn’t care except I’d like to add a RelateNG implementation for some of the currently unsupported predicates and I would like to not have to do so with all this “pretend const” infrastructure.
> 
> Does anyone know why all these pretty clearly non-const methods are declared const? Anyone have objections to removing the const keyword for these things? I have no idea how deep into the codebase such a removal would reach, but I’m guessing “not far”, the only folks who might be affected are C++ API users who have direct use of PreparedGeometry.
> 
> Thoughts?

I think "const" is referring to the geometry itself, which isn't changing.
Lazily creating caches may be considered an exception to be marked
with "mutable" for the cache object.

Compare with Geometry::intersects() which lazily computes the bounding box.

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20240809/b6932437/attachment.sig>