Implement P0009R18 <mdspan>
et al.
#3502
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been working on this for a while, but it's gotten to the point where if I hold it until it's fully implemented and tested, there won't be much time left to benchmark. Particularly for
extents
andlayout_stride
, there are different choices you could make about how to store the extents and strides that will affect codegen. If we want to investigate alternatives, it has to be done before ABI is locked. So @StephanTLavavej suggested I just submit what I have to a feature branch. I hope it's a useful starting point.I think
extents
,layout_left
, andlayout_right
are in the best shape. When there are constraints on constructors, I've tried to set up tests that each fail exactly one constraint. However, I've lately become doubtful aboutis_constructible
due to https://godbolt.org/z/q1M46rf6j. The last twostatic_assert
s fail, yet the corresponding definitions just above them don't compile. I've been replacing some of the positiveis_constructible
tests with actual definitions, but it's a work in progress.Other things that I know are not tested thoroughly:
index_type
vs.size_type
vs.rank_type
vs.size_t
.As for optimization, these are what I would look at if I had time:
std::array
, as a base class with a special case for zero dimensions, but without the indirection and debug codegen of using as actualstd::array
. Other options I can think of are just using astd::array
for simplicity, use one of the various algorithms for extracting the n-th member of a parameter pack, or use a recursive base class scheme liketuple
.layout_stride
. Here I just used astd::array
, to get the implementation done as quickly as possible.index_sequence
is used, sometimes I pass it to a function template and sometimes to a generic lambda. The lambda could cause code bloat if it's treated like an anonymous namespace, with internal linkage. But I think that identical instantiations in different TUs are supposed to be the same type andinline
, so the linker will discard the duplicates. If that's not the case, it might be better to convert everything to function templates.for
loops. I've usually preferred the latter for clarity, but you could probably convert any of them to a fold expression, possibly by introducing anindex_sequence
. I have no intution, though, about whether that would be better, worse, or about the same.I still hope to be involved, but it will likely have to be on narrow issues, as and when time permits.