Skip to content

Conversation

@spectre-ns
Copy link
Contributor

Checklist

  • [ x] The title and commit message(s) are descriptive.
  • [x ] Small commits made to fix your PR have been squashed to avoid history pollution.
  • [ x] Tests have been added for new features or bug fixes.
  • [ x] API of new functions and classes are documented.

@spectre-ns spectre-ns force-pushed the apply17 branch 2 times, most recently from 6ed414e to 569b615 Compare March 30, 2025 19:42
{
return self(self, std::size_t{i + 1}, t...);
}
XTENSOR_THROW(std::runtime_error, "Index applied to tuple of insufficient length");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@JohanMabille I think the noexcept specification here was too restrictive. We need to provide some way of indicating when index exceeds sizeof...(S). In the old implementation I think we would simply get an access violation which is not ideal.

Copy link
Member

Choose a reason for hiding this comment

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

The initial idea was to disable all checks to get the most opitmized generated code; I don't remember whether this function is used in critical parts of the code, so I cannot say for the NOEXCEPT, but I think we should prefer XTENSOR_ASSERT to XTENSOR_THROW.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved to assert. Clang compiles this code nicely... MSVC was a bit of a mess but I'm not sure if it's a code generation issue or just noise.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a link to the generated code. https://godbolt.org/z/sMdT517G4

It can calulate the result at compile time. Can I say it is the optimal solution then?

Copy link
Member

Choose a reason for hiding this comment

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

Haha yeah I think so ;)

{
using FT = std::add_pointer_t<R(F&&, const std::tuple<S...>&)>;
static const std::array<FT, sizeof...(I)> ar = {{&apply_one<R, F, I, S...>...}};
return ar[index](std::forward<F>(func), s);
Copy link
Contributor Author

@spectre-ns spectre-ns Mar 30, 2025

Choose a reason for hiding this comment

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

Potential access violation if index > I - 1.

return std::apply(
[&](const S&... args) -> R
{
return [&](const auto&... t) -> R
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need an additional lambda here? Can't we have the implementation directly in the lambda passed to std::apply ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops. Yeah... My bad.

@spectre-ns spectre-ns force-pushed the apply17 branch 3 times, most recently from 12be501 to cbf4fc0 Compare March 31, 2025 22:36
@spectre-ns
Copy link
Contributor Author

@JohanMabille I restored the noexcept specification and used an ASSERT as requested. Should be good to go!

@spectre-ns
Copy link
Contributor Author

Moved the noexcept assert to static assertions as they are known at compile time.

@spectre-ns spectre-ns force-pushed the apply17 branch 2 times, most recently from 9befbea to 464a7c5 Compare March 31, 2025 23:14
@JohanMabille
Copy link
Member

JohanMabille commented Apr 2, 2025

Thanks a lot!

@JohanMabille JohanMabille merged commit d0f0425 into xtensor-stack:master Apr 2, 2025
16 checks passed
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