[oneDPL][ranges][tests] a fix for std::ranges::<algo> using with Windows C++ standard library.

[MikeDvorskiy]

[oneDPL][ranges][tests] a fix for std::ranges::sort using with Windows C++ standard library.
This PR is a sequel for #1885.

[dmitriy-sobolev]

Could you introduce a similar macro in the tests in order not to rely on oneDPL internals?

[MikeDvorskiy]

I still strong disagree to make the code duplication.
Rather lets consider a an option to make public that macro....

[dmitriy-sobolev]

I do not think that having a public macro for that is a good idea given that it is a workaround for a niche issue, not resulting in enablement of any oneDPL feature. Also, I understand that duplication increases maintenance burden,
but I would duplicate this small code section to decouple the tests and implementation. I guess we need a mediator here.

[danhoeflinger]

Relocating my comment here, I missed this discussion in my initial review. I agree with Dmitriy here, this has been the convention as established by @akukanov.

We have tried to stay away from using internal helpers / utilities / implementation details in our tests.

If we want to use the same macro here, I think we probably want to re-define it here test/support/utils.h, or somewhere similar as _TEST_PREPARE_CALLABLE, or something like that, then use that throughout the tests.

[akukanov]

In the essence, here we have two good engineering practices contradicting each other, and we need to choose between "avoid code duplication" and "avoid test dependencies on implementation internals". I choose the second, because most if not all code duplications between the implementation and its tests are simple self-contained utilities or macros and duplicating those does not seem problematic to me.

Moreover, strictly speaking, the tests in this patch do not even have to use _ONEDPL_PREPARE_CALLABLE - range algorithms can always be wrapped into a lambda, possibly with a small "syntax sugar" helper.

Added: actually, since C++20 does not guarantee that range algorithms are function objects (this might change in C++26, but that's a separate question), the code that assumes that is at best implementation dependent. While we may want to do it in the implementation for the sake of performance or compilation efficiency (though it would better be proven with data as well), I see no single reason to do it in the tests. So I would say the tests should always wrap range algorithms into a lambda.

[MikeDvorskiy]

I see..
But we missed a way with passing a callable function by reference - foo(f&& f) - https://godbolt.org/z/j1P6MKdvn
Is the implementation of a C++ function/algorithm with doesn't match to foo(f&& f)?

Update: another issue in case of F&&:

<source>(18): error C2672: 'foo': no matching overloaded function found
<source>(18): error C2783: 'void foo(F &&)': could not deduce template argument for 'F'
<source>(8): note: see declaration of 'foo'

[dmitriy-sobolev]

The PR solves the problem, but I cannot decide whether to approve it or not due to the approach (using internal macro in the tests, using a macro, where it is possible to have an ordinary function). Let's add more reviewers for more opinions.

Update regarding "it is possible to have an ordinary function": I was not able to find such a solution. Providing specializations for signatures of specific algorithms (similar to the existing "checker" entities in the tests) is an alternative, but the solution with a macro is simpler.

[danhoeflinger]

I think I agree with the clang-format suggestions, but not a blocker for me.

[dmitriy-sobolev]

The PR looks good to me leaving aside a couple of issues easy to fix.