-
Notifications
You must be signed in to change notification settings - Fork 113
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
[oneDPL][ranges][test] + support arbitrary n for ranges tests #1908
base: main
Are you sure you want to change the base?
Conversation
MikeDvorskiy
commented
Oct 16, 2024
- [oneDPL][ranges][test] + support arbitrary n for 'data_in' test mode
template<typename Policy, typename DataGen> | ||
host_subrange_impl(Policy&&, int n, DataGen gen) | ||
{ | ||
mem = alloc.allocate(n); |
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.
allocate() produces uninitialized storage. You have to construct the objects first to avoid UB.
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.
- strictly speaking - "yes", but the tests use only trivial types so far and now we don't introduce new non-trival types.
- and the same thing was before the changes.
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.
Let's create an issue or leave a TODO comment in the test in order not to forget about it. You can also add a static_assert which makes sure that the type being tested is trivial.
~host_subrange_impl() | ||
{ | ||
if(mem) | ||
alloc.deallocate(mem, view.size()); |
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.
Here you need to destroy the objects first.
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 the comment above.
We use the trivial types that doesn't requires "special" destroying.
Probably, it makes sense to add a static assert to check triviality of type 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 agree regarding the static assert.
Container cont_in(exec, data_in, n_in); | ||
Container cont_out(exec, data_out, n_out); | ||
auto src_view = tr_in(std::views::all(cont_in())); | ||
auto out_view = tr_out(std::views::all(cont_exp())); |
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.
It looks like there should be cont_out
rather than cont_exp
, so that out_view
matches cont_out
.
Container cont_out(exec, data_out, n_out); | ||
auto src_view1 = tr_in(std::views::all(cont_in1())); | ||
auto src_view2 = tr_in(std::views::all(cont_in2())); | ||
auto expected_view = tr_in(std::views::all(cont_exp())); |
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.
Should you apply tr_out
to cont_exp
similarly to cont_out
below?