Skip to content
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

Feature/std23 stride #26

Merged
merged 6 commits into from
May 28, 2024
Merged

Feature/std23 stride #26

merged 6 commits into from
May 28, 2024

Conversation

whaeck
Copy link
Member

@whaeck whaeck commented May 7, 2024

In preparation for replacing range-v3 in ENDFtk, we need a few pieces defined in the c++23 standard: chunk, stride, zip, etc.

This adds the following:

std::conditional_t<
std20::ranges::bidirectional_range< Base >,
std20::bidirectional_iterator_tag,
std20::forward_iterator_tag > >;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a style change, yes? Is the goal to be consistent in this style? Can I put it like this:
if items inside < > extend more than 1 entry, then use a line break and add one entry per new line?

If this is the objective for consistent styling, template on line 80 needs to also be adjusted

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did this mainly for readability (the conditional is like a ternary statement). The style of these standard-like pieces of code is not as fixed as I would like it. I basically have not decided if we should use our normal style or something more like the nanorange style.

@@ -0,0 +1,139 @@
// include Catch2
#include <catch2/catch_test_macros.hpp>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add some more tests to this? The above is pretty complicated templating. While it looks like ok from a cursory look, I think it is very possible I mis-read the logic in a place or three. I'd like to see things like striding where we don't end on the last value, for instance. I get that this is temporary addition that will be replaced on adopting c++23 and we don't want to go too overboard, but testing more scenarios would increase my confidence that this is working as intended.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A valid point. And it did not work as it should have in this state. I actually added a test case later on to verify if these would work in our use cases in ENDFtk, see #27 for that test. I found multiple bugs because of it which are also corrected in that PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also should add more tests on the iterator operations (some of these are used under the hood in the view_interface functions but they most likely do not cover everything).

Base automatically changed from feature/std23-chunk-part2 to develop May 20, 2024 14:47
@whaeck whaeck merged commit 55c9c36 into develop May 28, 2024
8 checks passed
@whaeck whaeck deleted the feature/std23-stride branch May 28, 2024 17:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants