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

Adapting transform to C++20 (non-compilable PR) #4855

Closed
wants to merge 16 commits into from

Conversation

@gonidelis
Copy link
Contributor

gonidelis commented Jul 24, 2020

This is an early adaptation for transform. It includes:

  • adaptation for the end/begin iterators to be different in non-segmented transform
  • adaptation for the end/begin iterators to be different in segmented transform (didn't touch segmented_transform() functions though)
  • transform_projected specialization addition with util::projection_utility

To do

  • Add tests for the adaptations.

There is a compilation error when:

make tests.unit.modules.segmented_algorithms.partitioned_vector_transform_binary2 and
make tests.unit.modules.segmented_algorithms.partitioned_vector_transform_binary3

which I believe stems from the projection_identity addition but I can't figure out why.

  • Fix test compilation error for partitioned_vector_transform_binary2/3

Important

This is an early adaptation which aims to facilitate the final adaptation that will utilize CPOs.

@hkaiser hkaiser mentioned this pull request Jul 28, 2020
10 of 45 tasks complete
@gonidelis gonidelis force-pushed the gonidelis:transform_adapt branch from a628a03 to 4c09b6c Jul 30, 2020
@gonidelis gonidelis force-pushed the gonidelis:transform_adapt branch 2 times, most recently from d7bb53e to fc6c343 Jul 30, 2020
@gonidelis gonidelis force-pushed the gonidelis:transform_adapt branch from fc6c343 to 7d3f37c Jul 30, 2020
@gonidelis gonidelis force-pushed the gonidelis:transform_adapt branch from a6c7a1c to 993acc5 Jul 31, 2020
@gonidelis
Copy link
Contributor Author

gonidelis commented Jul 31, 2020

I have adapted the result types for all three overloads of transform. There are lots of compilation errors that come from the way tests are implemented. The errors stem from here:

HPX_TEST(hpx::util::get<0>(result) == iterator(std::end(c)));
HPX_TEST(hpx::util::get<1>(result) == std::end(d));

and here:

hpx::util::tuple<iterator, base_iterator> result = f.get();

as there is no get() function implemented for in_out_result or in_in_out_result types. I would like to discuss with @hkaiser on how to fix that.

  • I need to add a projection_identity specialization for transform_binary_projected.

After fixing the compilation issues on the tests, I think I should finally proceed on creating the CPO's.

{
return get_function_address<
typename hpx::util::decay<F>::type>::call(f.f_);
return std::transform(first, last, dest);

This comment has been minimized.

Copy link
@hkaiser

hkaiser Aug 7, 2020

Member

Calling the standard algorithms will have the correct semantics, but exposes inconsistent exception behavior. For the other algorithms we have settled on relying our own implementations even in those cases where semantically the standard version would be sufficient.

Copy link
Contributor

aurianer left a comment

Very nice ;)

traits::projected<Proj, FwdIter1>>::value
)>
//clang-format on
HPX_DEPRECATED("hpx::parallel::transform is deprecated, use hpx::transform instead")

This comment has been minimized.

Copy link
@aurianer

aurianer Aug 7, 2020

Contributor

@hkaiser should we use the HPX_DEPRECATED_V macro here?

This comment has been minimized.

Copy link
@hkaiser

hkaiser Aug 7, 2020

Member

Yes, that's what we use everywhere else now.

@@ -53,7 +53,7 @@ namespace hpx { namespace parallel { namespace util {
{
template <typename InIter1, typename InIter2, typename OutIter,
typename F>
HPX_HOST_DEVICE HPX_FORCEINLINE static hpx::util::tuple<InIter1,
HPX_HOST_DEVICE HPX_FORCEINLINE static util::in_in_out_result<InIter1,
InIter2, OutIter>
call(InIter1 first1, InIter1 last1, InIter2 first2, OutIter dest,

This comment has been minimized.

Copy link
@aurianer

aurianer Aug 7, 2020

Contributor

You may also want to adapt the begin/end iter template arguments for transform_loop too

This comment has been minimized.

Copy link
@gonidelis

gonidelis Aug 7, 2020

Author Contributor

Got it! Thanks!

@gonidelis gonidelis changed the title Transform adapt Adapting transform to C++20 Aug 7, 2020
@hkaiser hkaiser mentioned this pull request Aug 8, 2020
11 of 34 tasks complete
@gonidelis
Copy link
Contributor Author

gonidelis commented Aug 9, 2020

This PR is closed and archieved. The transform C++20 adaptation will take place in a new PR #4888.

@gonidelis gonidelis closed this Aug 9, 2020
@gonidelis gonidelis changed the title Adapting transform to C++20 Adapting transform to C++20 (non-compilable PR) Aug 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.