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

[oneDPL][ranges][test] + support arbitrary n for ranges tests #1908

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

MikeDvorskiy
Copy link
Contributor

  1. [oneDPL][ranges][test] + support arbitrary n for 'data_in' test mode

@MikeDvorskiy MikeDvorskiy marked this pull request as draft October 16, 2024 16:29
@MikeDvorskiy MikeDvorskiy marked this pull request as ready for review October 17, 2024 10:48
test/parallel_api/ranges/std_ranges_adjacent_find.pass.cpp Outdated Show resolved Hide resolved
test/parallel_api/ranges/std_ranges_test.h Show resolved Hide resolved
test/parallel_api/ranges/std_ranges_test.h Show resolved Hide resolved
test/parallel_api/ranges/std_ranges_test.h Show resolved Hide resolved
template<typename Policy, typename DataGen>
host_subrange_impl(Policy&&, int n, DataGen gen)
{
mem = alloc.allocate(n);
Copy link
Contributor

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.

Copy link
Contributor Author

@MikeDvorskiy MikeDvorskiy Oct 18, 2024

Choose a reason for hiding this comment

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

  1. strictly speaking - "yes", but the tests use only trivial types so far and now we don't introduce new non-trival types.
  2. and the same thing was before the changes.

Copy link
Contributor

@dmitriy-sobolev dmitriy-sobolev Oct 18, 2024

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());
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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()));
Copy link
Contributor

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()));
Copy link
Contributor

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?

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