Make RelationRange a proper view#727
Merged
tmadlener merged 1 commit intoAIDASoft:masterfrom Jan 21, 2025
Merged
Conversation
39a6337 to
e6b4b24
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
BEGINRELEASENOTES
RelationRangefulfill thestd::ranges::viewandstd::ranges::borrowed_rangeconceptsENDRELEASENOTES
As suggested in #626 (comment) adding tests for checking whether
RelationRangeis a std range - it is.Since the
RelationRangeis a very lightweight, non-owning view it can fulfill two more concepts that can be used by the std range algorithms and adapters to avoid unneeded operations:view- it's cheap to move/copy as it stores only iterators to the data living elsewhereborrowed_range- the iterators taken from range remain valid even when the range is destroyed since they are not local to the rangeThe
RelationRangeis very similar tostd::spanandstd::ranges::subrangeand could potential replaced by them except for two differences:RealationRangehasatfor bound-check element access whereas the alternatives don't (until C++26)RelationRangeelement access returns copy whereas the alternatives would return const reference. Since the elements are podio objects then copy is preferred.The
RelationRangecould be also re-implemented withstd::ranges::view_interfacebut it comes with issues like above so I think isn't really worth it