-
Notifications
You must be signed in to change notification settings - Fork 83
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] view_translate_join #1171
Conversation
910a959
to
4f240ca
Compare
Codecov Report
@@ Coverage Diff @@
## master #1171 +/- ##
==========================================
+ Coverage 96.45% 96.47% +0.02%
==========================================
Files 201 202 +1
Lines 7752 7803 +51
==========================================
+ Hits 7477 7528 +51
Misses 275 275
Continue to review full report at Codecov.
|
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.
Looks very good already, just a bunch of minor comments.
//!\cond | ||
requires !std::Same<remove_cvref_t<rng_t>, view_translate_join> && | ||
std::ranges::ViewableRange<rng_t> && | ||
std::Constructible<urng_t, ranges::ref_view<std::remove_reference_t<rng_t>>> |
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.
std::Constructible<urng_t, ranges::ref_view<std::remove_reference_t<rng_t>>> | |
std::Constructible<urng_t, all_view<rng_t>> |
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.
std::Constructible<urng_t, ranges::ref_view<std::remove_reference_t<rng_t>>> | |
std::Constructible<urng_t, std::ranges::all_view<rng_t>> |
4f240ca
to
ba91828
Compare
@h-2 Should we also have an iterator test for all nucleotide alphabets? |
//!\cond | ||
requires !std::Same<remove_cvref_t<rng_t>, view_translate_join> && | ||
std::ranges::ViewableRange<rng_t> && | ||
std::Constructible<urng_t, ranges::ref_view<std::remove_reference_t<rng_t>>> |
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.
std::Constructible<urng_t, ranges::ref_view<std::remove_reference_t<rng_t>>> | |
std::Constructible<urng_t, std::ranges::all_view<rng_t>> |
We shouldn't need to add this here, but the simple view::translate_single should eventually get those for all nucleotides... |
I cannot comment under the suggestion for some reason .. Sorry that I did not make it clearer. All your changes using |
ba91828
to
89e953d
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.
Iterator template looks good :)
*/ | ||
template <std::ranges::View urng_t> | ||
//!\cond | ||
requires std::ranges::SizedRange<urng_t> && |
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.
I guess those requirements are not needed for overload resolution but just for "type cheking"? If so we decided to use static asserts rather than concet. The error messages are more readable :)
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.
Isn't it enough that the concepts are checked via static_assert in the adaptor? This gets anyways called when constructing the view, right?
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.
There is a general rule in SeqAn about having static_asserts instead of requirements if they are not required for overload resolution. For the regular translate views I would argue that we might actually add other overloads and in that case the constraints for this class
would be the same, but we would change the constraints on the adaptor (which would then allow e.g. BidirectionalRange but would forward those to view::translate | view::join
).
TLDR: It doesn't make much of a difference. Since I don't think this particular class will get another specialisation, you can also just copy the static assert from the adaptor into the class and remove the concept constraints.
decltype(view::translate_join(vec)) test_range = view::translate_join(vec); | ||
|
||
template <typename A, typename B> | ||
static void expect_eq(A && begin_iterator_value, B && expected_range_value) |
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.
static void expect_eq(A && begin_iterator_value, B && expected_range_value) | |
static void expect_eq(A && test_range_value, B && expected_range_value) |
💅 but not neccessary
89e953d
to
53409b8
Compare
53409b8
to
285774e
Compare
285774e
to
e2fa839
Compare
@smehringer Do you want a final review or can I merge this after CI passes? |
This PR introduces the
view_translate_join
view_translate