Use canonicalize slices in submdspan#457
Conversation
crtrott
force-pushed
the
use-canonicalize-slice-in-submdspan
branch
from
9316c0a to
6729b41
Compare
| #define MDSPAN_HAS_CXX_17 (MDSPAN_IMPL_CPLUSPLUS >= MDSPAN_CXX_STD_17) | ||
| #define MDSPAN_HAS_CXX_20 (MDSPAN_IMPL_CPLUSPLUS >= MDSPAN_CXX_STD_20) | ||
| #define MDSPAN_HAS_CXX_23 (MDSPAN_IMPL_CPLUSPLUS >= MDSPAN_CXX_STD_23) | ||
| #define MDSPAN_HAS_CXX_26 (MDSPAN_IMPL_CPLUSPLUS >= MDSPAN_CXX_STD_26) |
There was a problem hiding this comment.
Given that this is for checking whether std::complex is tuple-like, should we consider having a finer-grained check? The feature test macro check would look like this,
(__cpp_lib_tuple_like >= 202311L)
as P2819 updated the value from 202207L.
There was a problem hiding this comment.
On the other hand, we might later want to use this macro for other C++26 features like parameter pack indexing.
There was a problem hiding this comment.
Yeah we could test more finely for the tuple-like I guess? But we can have the CXX26 thing anyway.
| SliceSpecifiers... slices) { | ||
| const auto sub_submdspan_mapping_result = submdspan_mapping(src.mapping(), slices...); | ||
|
|
||
| // Avoid instantiating expensive slice mandate check here for known layouts |
There was a problem hiding this comment.
Are the known layouts just calling this function anyway? If so, then it might not be much more expensive to do it twice, since you've already instantiated the function once.
There was a problem hiding this comment.
Not sure if it actually caches that properly ...
There was a problem hiding this comment.
@crtrott What I'm getting at is that we're diverging from the plain wording of the Standard for the sake of an unproven optimization. It adds a compile-time check, so it's not an obvious win.
crtrott
force-pushed
the
use-canonicalize-slice-in-submdspan
branch
from
6729b41 to
526a039
Compare
Signed-off-by: Christian Trott <crtrott@sandia.gov>
crtrott
force-pushed
the
use-canonicalize-slice-in-submdspan
branch
from
526a039 to
7bc13a6
Compare
3 participants
This is the last piece to be extracted from PR #408 to implement P3663. After this we need to introduce
extent_slice.