named access to Vec
#2201
named access to Vec
#2201
Conversation
psychocoderHPC
force-pushed
the
topic-namedVectorAccess
branch
from
aead57d to
0598384
Compare
include/alpaka/vec/Vec.hpp
Outdated
| template<typename TDefer = Dim> | ||
| ALPAKA_FN_HOST_ACC constexpr auto x() const | ||
| -> std::enable_if_t<std::is_same_v<TDefer, Dim> && Dim::value >= 1, TVal const&> |
There was a problem hiding this comment.
I am personally a fan of putting enable_if into the template parameter list for better readability. This may also remove the need to delay instantiation as you did with TDefer. I have not tested it though.
| template<typename TDefer = Dim> | |
| ALPAKA_FN_HOST_ACC constexpr auto x() const | |
| -> std::enable_if_t<std::is_same_v<TDefer, Dim> && Dim::value >= 1, TVal const&> | |
| template<std::enable_if_t<std::is_same_v<TDefer, Dim> && Dim::value >= 1, int> = 0> | |
| ALPAKA_FN_HOST_ACC constexpr auto x() const -> TVal const& |
There was a problem hiding this comment.
I took your suggestion because this allow the usage of decltype(auto)
There was a problem hiding this comment.
Why would you want to use decltype(auto) over just TVal& and TVal const&?
There was a problem hiding this comment.
Avoids copy past errors^^. IMO defining RefType and ConstRefType or similar would be better than writing everywhere TVal&.
There was a problem hiding this comment.
Avoids copy past errors^^. IMO defining
RefTypeandConstRefTypeor similar would be better than writing everywhereTVal&.
That's even worse in my opinion. I value readability and auto x() -> TVal& is more readable than decltype(auto) x() or auto x() -> RefType. The former requires me to look at the function body, the latter requires me to lookup what RefType is.
But in any case, I was just curious. I leave this up to you!
There was a problem hiding this comment.
static_assert() works without the need for TDefer, and lets us provide a more readable error message:
ALPAKA_FN_HOST_ACC constexpr decltype(auto) x() const
{
static_assert(Dim::value >= 1, ".x() is defined only for Vec types with a dimension of 1 or more.");
return m_data[Dim::value - 1];
}There was a problem hiding this comment.
@fwyzard Your suggestion will prevent you can check from the user code side if Vec is allowing the call to the method z(). I know that the defer in the template signature is ugly but the function is cleanly disabled if not supported.
There was a problem hiding this comment.
What do you mean, to check from user code ?
There was a problem hiding this comment.
The version from @psychocoderHPC is SFINAE-friendly, whereas a static_assert is not:
if constexpr (requires { v.y() }) ...Works with the version here for a 1D vector v, but fails with a hard error using a static_assert.
fix alpaka-group#2185 Provide access to the vector components via named methods. `x()`, `y()`, `z()` and `w()`. The avalble names depends on the dimension of the vector.
psychocoderHPC
force-pushed
the
topic-namedVectorAccess
branch
from
0598384 to
94240c8
Compare
fix #2185
Provide access to the vector components via named methods.
x(),y(),z()andw().The available names depend on the dimension of the vector.