CoordinateSequence: Add type-detecting forEach (requires C++14) #800
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As a follow-on to the introduction of XY, XYM and XYZM Coordinate types to GEOS, I have been exploring the feasibility of supporting these coordinate types in the overlay operations. Consistent with the new
CoordinateSequenceimplementation, a design goal is to avoid a penalty for M values in cases where they are not used. (Good news: it's already working for simple cases such as line intersections).One problem I have come across several times already is the need to perform some operation to each coordinate in a sequence, in type-generic but type-preserving way. For example,
OverlayMixedPoints::findPointsneeds to read aCoordinateSequence, find unique coordinates matching a certain condition that only requires use of X and Y, and write them to an outputCoordinateSequence.One way do do this is to copy everything into a
CoordinateXYZMwhen we read it:Of course, the problem here is that we copy the coordinate every time we handle it, which goes against the goal by introducing a new performance penalty for XY and XYZ operations. If we want to avoid the copy, we need to work with references matching the actual backing type of the
CoordianteSequence.The simplest way to do this is by checking the backing type of theCoordinateSequenceand providing an implementation for each type, for example:That's simple and also very repetitive. In #799, I proposed a
CoordinateInspectorbase class that lets you provide a template that hooks into the existingCoordinateFiltermachinery. So instead of the code above, you could writeThis avoids repeating the implementation, but is harder to read and requires a lot of tedious plumbing. We can't define the template at the spot where it's used, we need to bring in any variables the implementation requires as member variables, write a contructor, etc. A much cleaner solution is available with auto lambdas:
The problem (?) with the above is that it requires C++14. Switching to C++14 may sound like a disruptive change but in practice should have no effect. C++14 is fully supported by all of our CI environments including gcc 5. C++14 is not supported by gcc 4.8, but GEOS already does not build on gcc 4.8 since #726.