On 9/11/25 9:40 AM, Tomasz Kaminski wrote:
---------------------------------------------------------
The tests contain a function:
constexpr bool
is_same_mapping(const auto& lhs, const auto& rhs)
// ...
for (size_t i = 0; i < lhs.extents().rank(); ++i)
if (lhs.stride(i) != rhs.stride(i))
return false;
return true;
}
The above is accidentally quadratic, because computing all strides can
be done in linear time, but not if one computes them one by one, then
it's quadratic. It's annoyingly hard to do in linear time, because it
requires both precise knowledge of the definition of `stride` for each
layout; and ideally it also requires access to implementation details
related to how we separate static and dynamic extents to be able to
compute static products at compile time.
I think this is fine for tests, as long as they run in reasonable time,
which seems to be the case one.
Fully agree. However, it seems like computing all strides
in one go is a "common" operation that with the current API
users are force to do a) manually and b) in quadratic time.
Moreover, some layouts have a strides() member, others don't.
It would be easier if they all had one :)
I think requiring them for all mappings (including user-defined ones)
is no go. However, we could add them for standard defined ones, however
That is a design change and would require a separate committee paper.
What are the chances of such a paper succeeding? I suspect it would
be a short paper.
Do we need a member strides() for all strided layout mappings to avoid
the issue?
We cannot add them, if the standard does not specify them.
Yes, I should have been clearer on that point. Add referred to getting
it standardized, i.e. add to the standard and then add to libstdc++.
