-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Unify proxy iterator types #3664
refactor: Unify proxy iterator types #3664
Conversation
d00ec45
to
20cf5fc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would be easier / beneficial to define it as a random access iterator?
Hmm, probably; I can do that! |
20cf5fc
to
eff6a58
Compare
This PR has changed scope; rather than have it implement random access only for the measurement iterator, it now captures the proxy iterator for all such containers we have; for measurements but also tracks and spacepoints. |
eff6a58
to
a43c26e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea
53b62c8
to
a30e446
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The copyright statement has been changed
fd31c85
to
b5cd817
Compare
We have quite a few container types whose iterators are container-index pairs. These currently have different implementations which can be fairly easily unified under a single template.
Quality Gate passedIssues Measures |
This PR changed scope, and now unifies all proxy iterators under a single template type.
Old PR description
At this point in time, the iterator for
MeasurementContainer
does not match thestd::forward_iterator
concept which SonarCloud really wants me to use. In this commit, I make sure that the iterator satisfies the concept.Unfortunately, this requires a default-initializer, because
std::forward_iterator
requiresstd::incrementable
which requiresstd::regular
, which requiresstd::semiregular
which in turn requiresstd::default_initializable
which I think is silly.