The constructors that are inside mapping_left, that I think represents
constructors with other extends:
template<class U>
mapping_left(const mapping_left_base<N, U>& other)
: mapping_left_base<N, double>(other) {}
Can be placed in mapping_left_base, and they will be inherited, as only
copy/move constructors are shadowed.
On Tue, May 6, 2025 at 9:11 AM Tomasz Kaminski <tkami...@redhat.com> wrote:
>
>
> On Mon, May 5, 2025 at 9:20 PM Luc Grosheintz <luc.groshei...@gmail.com>
> wrote:
>
>>
>>
>> On 5/5/25 9:44 AM, Tomasz Kaminski wrote:
>> > On Sat, May 3, 2025 at 2:39 PM Luc Grosheintz <luc.groshei...@gmail.com
>> >
>> > wrote:
>> >
>> >>
>> >>
>> >> On 4/30/25 7:13 AM, Tomasz Kaminski wrote:
>> >>> Hi,
>> >>>
>> >>> As we will be landing patches for extends, this will become a separate
>> >>> patch series.
>> >>> I would prefer, if you could commit per layout, and start with
>> >> layout_right
>> >>> (default)
>> >>> I try to provide prompt responses, so if that works better for you,
>> you
>> >> can
>> >>> post a patch
>> >>> only with this layout first, as most of the comments will apply to
>> all of
>> >>> them.
>> >>>
>> >>> For the general design we have constructors that allow conversion
>> between
>> >>> rank-0
>> >>> and rank-1 layouts left and right. This is done because they
>> essentially
>> >>> represents
>> >>> the same layout. I think we could benefit from that in code by having
>> a
>> >>> base classes
>> >>> for rank0 and rank1 mapping:
>> >>> template<typename _Extents>
>> >>> _Rank0_mapping_base
>> >>> {
>> >>> static_assert(_Extents::rank() == 0);
>> >>>
>> >>> template<OtherExtents>
>> >>> // explicit, requires goes here
>> >>> _Rank0_mapping_base(_Rank0_mapping_base<OtherExtents>);
>> >>>
>> >>> // All members layout_type goes her
>> >>> };
>> >>>
>> >>> template<typename _Extents>
>> >>> _Rank1_mapping_base
>> >>> {
>> >>> static_assert(_Extents::rank() == 1);
>> >>> // Static assert for product is much simpler here, as we need to
>> >> check one
>> >>>
>> >>> template<OtherExtents>
>> >>> // explicit, requires goes here
>> >>> _Rank1_mapping_base(_Rank1_mapping_base<OtherExtents>);
>> >>>
>> >>> // Call operator can also be simplified
>> >>> index_type operator()(index_type i) const // conversion happens at
>> >> user
>> >>> side
>> >>>
>> >>> // cosntructor from strided_layout of Rank1 goes here.
>> >>>
>> >>> // All members layout_type goes her
>> >>> };
>> >>> Then we will specialize layout_left/right/stride to use
>> >> _Rank0_mapping_base
>> >>> as a base for rank() == 0
>> >>> and layout_left/right to use _Rank1_mapping as base for rank()1;
>> >>> template<typename T, unsigned... Ids>
>> >>> struct extents {};
>> >>>
>> >>> struct layout
>> >>> {
>> >>> template<typename Extends>
>> >>> struct mapping
>> >>> {
>> >>> // static assert that Extents mmyst be specialization of _Extents goes
>> >> here.
>> >>> }
>> >>> };
>> >>>
>> >>> template<typename _IndexType>
>> >>> struct layout::mapping<extents<_IndexType>>
>> >>> : _Rank0_mapping_base<extents<_IndexType>>
>> >>> {
>> >>> using layout_type = layout_left;
>> >>> // Provides converting constructor.
>> >>> using _Rank0_mapping_base<extents<_IndexType>>::_Rank0_mapping_base;
>> >>> // This one is implicit;
>> >>> mapping(_Rank0_mapping_base<extents<_IndexType>> const&);
>> >>> };
>> >>>
>> >>> template<typename _IndexType, unsigned _Ext>
>> >>> struct layout::mapping<extents<_IndexType, _Ext>>
>> >>> : _Rank1_mapping_base<extents<_IndexType>>
>> >>>
>> >>> {
>> >>> using layout_type = layout_left;
>> >>> // Provides converting constructor.
>> >>> using _Rank0_mapping_base<extents<_IndexType>>::_Rank0_mapping_base;
>> >>> // This one is implicit, allows construction from layout_right
>> >>> mapping(_Rank1_mapping_base<extents<_IndexType>> const&);
>> >>> };
>> >>> };
>> >>>
>> >>> template<typename _IndexType, unsigned... _Ext>
>> >>> requires sizeof..(_Ext) > = 2
>> >>> struct layout::mapping<extents<_IndexType, _Ext>>
>> >>>
>> >>> The last one is a generic implementation that you can use in yours.
>> >>> Please also include a comment explaining that we are deviating from
>> >>> standard text here.
>> >>>
>> >>
>> >> Thank for reviewing and offering fast review cycles, I can't say I've
>> >> ever felt that they were anything but wonderfully fast and I appologise
>> >> for the delay (I've been away hiking for two days).
>> >>
>> >> The reason I implement all three is that I needed to see them all.
>> >> Otherwise, I can see and "feel" the impact of the duplication (or
>> >> efforts to reduce duplication). It's also to make sure I understand
>> >> precisely how the layouts are similar and different. The idea is that
>> >> you'd review one at a time; and by adding the others you can pick which
>> >> one and have a glance at the other if it's helpful during review.
>> >>
>> >> The review contains three topics. This email responds to the idea of
>> >> introducing a common base class. I believe I superficially understand
>> >> the request. However, it's not clear to me what we gain.
>> >>
>> >> The reorganization seems to stress the how rank 0 and rank 1 layouts
>> are
>> >> similar; at the cost of making the uniformity of layout_left
>> (regardless
>> >> of rank) and layout_right (regardless of rank) less obvious.
>> Personally,
>> >> I quite like that we can express all layouts of one kind regardless of
>> >> their rank, without resorting to special cases via specialization.
>> >>
>> >> To me the standard reads like the layouts are three separate,
>> >> independent entities. However, because it would be too tedious to not
>> >> allow conversion between layouts of rank 0 and 1, a couple of ctors
>> were
>> >> added. An example, of how the layouts are not consider related is that
>> >> we can't compare layout_left and layout_right mappings for equality.
>> >>
>> >> If I count, the current implementation has 3 copies: layout_left,
>> >> layout_right, layout_stride. The proposed changes add two (likely
>> three)
>> >> base classes which, require three specializations of layout_right and
>> >> layout_left each. Therefore I end up with 6 copies of layout_left and
>> >> layout_right; and 2 (or 3) base classes. Or if we manage it use the
>> base
>> >> classes for all layouts: 9 specialization, 2 (or 3) base classes.
>> >> Therefore, in terms of numbers the restructuring doesn't seem
>> favourable
>> >> and I feel would require noticeably more repetition in the tests.
>> >>
>> > I think we can use a conditional base, to eliminate specializations,
>> > and have layout_left_base.
>> >
>> >>
>> >> While the rank zero and rank one versions are a lot simpler than the
>> >> generic copy, they aren't entirely empty either (we'll likely need to
>> >> use `using super::*` several times). Furthermore, I don't see any real
>> >> simplifications in the generic copy. Meaning we still have a copy that
>> >> has all the complexities and could (almost) handle the other two cases.
>> >>
>> > I think using a common bases, and allowing layout_left/layout_right to
>> be
>> > constructed from the base classes, will automatically enable the
>> conversions
>> > that are currently expressed via constructor:
>> > layout_left <-> layout_right for ranks 0 and 1,
>> > layout_stride <-> layout_left/right for rank 0 (because they are rank0)
>> >
>> >>
>> >> Since layout_stride is a little different, I'm not sure we can reuse
>> the
>> >> base classes for it. For example it allows conversion more freely, but
>> >> is only implicit for rank 0; whereas the other two allow implicit
>> >> conversion between each other for rank 0 and 1.
>> >>
>> > This is why I said rank0_mapping_base should be used for layout_left,
>> > layout_rigth and layout_stride
>> > (and later layout_left_padeed, and layout_right_padded).
>> > For rank1 this would be shared between layout_left, laout_right,
>> > layout_left_paded and layout_right_paded.
>> >
>> >>
>> >> Most importantly though, the reorganization makes it very hard to
>> >> compare the implementation with the text of the standard. Therefore,
>> >> making it more likely that a discrepancy goes unnoticed.
>> >>
>> >> One example of the subtleties involved in restructuring the code is the
>> >> following: layout_right, layout_left support CTAD via the ctor
>> >> `mapping(extents_type)`. However, when using specialization, that stops
>> >> working and we'd need to add deduction guides to make the
>> implementation
>> >> conforming. I suspect a Godbolt can explain the situation better:
>> >> https://godbolt.org/z/EdbE7ME6P
>> >
>> > We could use simple specializations, and derive from different base
>> classes
>> > using conditional_t. This would require having
>> >
>>
> Thank you for looking deep into that idea, before we would go with totally
> separate classes,
> I would like to understands your points.
>
>>
>> I gave this another try; and now I'm stumbling again as show here:
>> https://godbolt.org/z/hfh9zE8ME
>
> This could be done as:
> template<size_t N, typename T>
> using mapping_middle_base = std::conditional_t<N == 0, rank0_base<T>,
> rankN_middle_base<T>>;
>
> template<size_t N>
> class mapping_middle : public mapping_middle_base<N, double>
> {
> using _Base = mapping_middle_base<N, double>;
> public:
> using _Base::_Base;
>
> mapping_middle(const _Base& other)
> {}
> };
> https://godbolt.org/z/M7jxq6qTK
>
>>
>>
>> As shown, it could be solved using three ctors `mapping(_Rank0_base)`,
>> `mapping(_Rank1_base)` and `mapping(_RankN_base)` with the respective
>> `requires` clauses. However that feels like it defeats the purpose.
>>
> I was thinking about having a simple constructor that constructs from
> _Base.
>
>>
>> Frankly, the savings in terms of lines of code are not great. Partly,
>> because we often need `using extents_type = __super::extents`; or
>> the ctor `mapping(mapping_base<OExtents>&)`.
>>
> I see that I was unclear there, my point was not about the code size in
> terms of source file,
> but the emitted code into binary. What I mean with separate layouts, for
> E being every
> static extent and and dynamic_extent, and every member function `fun` we
> will have:
> layout_left<extends<E>>::fun();
> layout_right<extends<E>>::fun();
> layout_left_padded<extends<E>>::fun();
> layout_right_padded<extends<E>>::fun();
> emitted in binary, and I would like to see if we can reduce it to
> rank1_mapping_base<extends<E>>::fun();
> That's why I am looking into base class direction.
>
>
>> The generic cases of `operator()`, `stride`, `required_span_size` tend
>> to supported the rank 0 and rank 1 without special cases. (Making it
>> harder to save lines of code by having special cases for rank 0, 1 and
>> N.)
>>
> Again, I was not clear, when referring to code size, and more thinking of
> binary size
> and number of symbols.
>
>>
>> The `stride` is a nice example of how it's all almost uniform, but not
>> quite. It's present for layout_stride and the padded ones, but not
>> layout_left and layout_right. For rank 1 it works for anything, just not
>> layout_stride. (Further reducing the savings in terms of lines of code.)
>>
>> >>
>> >>
>> >> In summary: personally I feel using base classes adds repetition,
>> >> complexity and makes it hard (for me impossible) to check that the
>> >> implementation is conforming.
>> >>
>> >> Naturally, I can be convinced to change the implementation. Maybe you
>> >> could explain a little what and why you don't like the admittedly very
>> >> brute-force implementation.
>> >>
>> > There are a few things I had in mind. For rank 1 checking the
>> precondition
>> > for the size of multidimensional index space is trivial,
>> > and we certainly could provide a __glibcxx_assert in such a case. This
>> can
>> > be done for the separate implementation, but I think
>> > we will end up with repeated if constexpr checks in all mappings. This
>> is
>> > why in my mind, the reduced rank0 and rank1 cases
>> > felt a bit special.
>> > For example, mdspan<T, extents<N>> can be seen as replacement for
>> span<N>,
>> > which provides support for adjusting accessor
>> > and pointer type.
>> >
>> > My original request, however, was however driven by code size. The
>> > layout_left, layout_right, layout_left_padded, layout_right_padded
>> > with rank 0, have members with same semantics (operator(), stride, ...),
>> > and we could have only one definition for them, instead of four.
>> >
>> >>
>> >>>
>> >>> On Tue, Apr 29, 2025 at 2:56 PM Luc Grosheintz <
>> luc.groshei...@gmail.com
>> >>>
>> >>> wrote:
>> >>>
>> >>>> Implements the parts of layout_left that don't depend on any of the
>> >>>> other layouts.
>> >>>>
>> >>>> libstdc++/ChangeLog:
>> >>>>
>> >>>> * include/std/mdspan (layout_left): New class.
>> >>>>
>> >>>> Signed-off-by: Luc Grosheintz <luc.groshei...@gmail.com>
>> >>>> ---
>> >>>> libstdc++-v3/include/std/mdspan | 179
>> ++++++++++++++++++++++++++++++++
>> >>>> 1 file changed, 179 insertions(+)
>> >>>>
>> >>>> diff --git a/libstdc++-v3/include/std/mdspan
>> >>>> b/libstdc++-v3/include/std/mdspan
>> >>>> index 39ced1d6301..e05048a5b93 100644
>> >>>> --- a/libstdc++-v3/include/std/mdspan
>> >>>> +++ b/libstdc++-v3/include/std/mdspan
>> >>>> @@ -286,6 +286,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> >>>>
>> >>>> namespace __mdspan
>> >>>> {
>> >>>> + template<typename _Extents>
>> >>>> + constexpr typename _Extents::index_type
>> >>>> + __fwd_prod(const _Extents& __exts, size_t __r) noexcept
>> >>>> + {
>> >>>> + typename _Extents::index_type __fwd = 1;
>> >>>> + for(size_t __i = 0; __i < __r; ++__i)
>> >>>> + __fwd *= __exts.extent(__i);
>> >>>> + return __fwd;
>> >>>> + }
>> >>>>
>> >>> As we are inside the standard library implementation, we can do some
>> >> tricks
>> >>> here,
>> >>> and provide two functions:
>> >>> // Returns the std::span(_ExtentsStorage::_Ext).substr(f, l);
>> >>> // For extents forward to __static_exts
>> >>> span<typename Extends::index_type> __static_exts(size_t f, size_t l);
>> >>> // Returns the
>> >>>
>> >>
>> std::span(_ExtentsStorage::_M_dynamic_extents).substr(_S_dynamic_index[f],
>> >>> _S_dynamic_index[l);
>> >>> span<typename Extends::index_type> __dynamic_exts(Extents const& c);
>> >>> Then you can befriend this function both to extents and
>> _ExtentsStorage.
>> >>> Also add index_type members to _ExtentsStorage.
>> >>>
>> >>> Then instead of having fwd-prod and rev-prod I would have:
>> >>> template<typename _Extents>
>> >>> consteval size_t __static_ext_prod(size_t f, size_t l)
>> >>> {
>> >>> // multiply E != dynamic_ext from __static_exts
>> >>> }
>> >>> constexpr size __ext_prod(const _Extents& __exts, size_t f, size_t l)
>> >>> {
>> >>> // multiply __static_ext_prod<_Extents>(f, l) and each elements
>> of
>> >>> __dynamic_exts(__exts, f, l);
>> >>> }
>> >>>
>> >>> Then fwd-prod(e, n) would be __ext_prod(e, 0, n), and rev_prod(e, n)
>> >> would
>> >>> be __ext_prod(e, __ext.rank() -n, n, __ext.rank())
>> >>>
>> >>>
>> >>>> +
>> >>>> + template<typename _Extents>
>> >>>> + constexpr typename _Extents::index_type
>> >>>> + __rev_prod(const _Extents& __exts, size_t __r) noexcept
>> >>>> + {
>> >>>> + typename _Extents::index_type __rev = 1;
>> >>>> + for(size_t __i = __r + 1; __i < __exts.rank(); ++__i)
>> >>>> + __rev *= __exts.extent(__i);
>> >>>> + return __rev;
>> >>>> + }
>> >>>> +
>> >>>> template<typename _IndexType, size_t... _Counts>
>> >>>> auto __build_dextents_type(integer_sequence<size_t,
>> _Counts...>)
>> >>>> -> extents<_IndexType, ((void) _Counts,
>> dynamic_extent)...>;
>> >>>> @@ -304,6 +324,165 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> >>>> explicit extents(_Integrals...) ->
>> >>>> extents<size_t,
>> __mdspan::__dynamic_extent<_Integrals>()...>;
>> >>>>
>> >>>> + struct layout_left
>> >>>> + {
>> >>>> + template<typename _Extents>
>> >>>> + class mapping;
>> >>>> + };
>> >>>> +
>> >>>> + namespace __mdspan
>> >>>> + {
>> >>>> + template<typename _Tp>
>> >>>> + constexpr bool __is_extents = false;
>> >>>> +
>> >>>> + template<typename _IndexType, size_t... _Extents>
>> >>>> + constexpr bool __is_extents<extents<_IndexType, _Extents...>>
>> =
>> >>>> true;
>> >>>> +
>> >>>> + template<size_t _Count>
>> >>>> + struct _LinearIndexLeft
>> >>>> + {
>> >>>> + template<typename _Extents, typename... _Indices>
>> >>>> + static constexpr typename _Extents::index_type
>> >>>> + _S_value(const _Extents& __exts, typename
>> _Extents::index_type
>> >>>> __idx,
>> >>>> + _Indices... __indices) noexcept
>> >>>> + {
>> >>>> + return __idx + __exts.extent(_Count)
>> >>>> + * _LinearIndexLeft<_Count + 1>::_S_value(__exts,
>> >> __indices...);
>> >>>> + }
>> >>>> +
>> >>>> + template<typename _Extents>
>> >>>> + static constexpr typename _Extents::index_type
>> >>>> + _S_value(const _Extents&) noexcept
>> >>>> + { return 0; }
>> >>>> + };
>> >>>> +
>> >>>> + template<typename _Extents, typename... _Indices>
>> >>>> + constexpr typename _Extents::index_type
>> >>>> + __linear_index_left(const _Extents& __exts, _Indices...
>> >> __indices)
>> >>>> + {
>> >>>> + return _LinearIndexLeft<0>::_S_value(__exts, __indices...);
>> >>>> + }
>> >>>>
>> >>> This can be eliminated by fold expressions, see below.
>> >>>
>> >>>> +
>> >>>> + template<typename _IndexType, typename _Tp, size_t _Nm>
>> >>>> + consteval bool
>> >>>> + __is_representable_product(array<_Tp, _Nm> __factors)
>> >>>> + {
>> >>>> + size_t __rest = numeric_limits<_IndexType>::max();
>> >>>> + for(size_t __i = 0; __i < _Nm; ++__i)
>> >>>> + {
>> >>>> + if (__factors[__i] == 0)
>> >>>> + return true;
>> >>>> + __rest /= _IndexType(__factors[__i]);
>> >>>> + }
>> >>>> + return __rest > 0;
>> >>>> + }
>> >>>>
>> >>> I would replace that with
>> >>> template<IndexType>
>> >>> consteval size_t __div_reminder(span<const size_t, _Nm> __factors,
>> size_t
>> >>> __val)
>> >>> {
>> >>> size_t __rest = val;
>> >>> for(size_t __i = 0; __i < _Nm; ++__i)
>> >>> {
>> >>> if (__factors[__i] == dynamic_extent)
>> >>> continue;
>> >>> if (__factors[__i] != 0)
>> >>> return val;
>> >>> __rest /= _IndexType(__factors[__i]);
>> >>> if (__res == 0)
>> >>> return 0;
>> >>> }
>> >>> return __rest;
>> >>> }
>> >>>
>> >>> We can express the is presentable check as
>> >>> static constexpr __dyn_reminder =
>> >> __div_reminder(__static_exts<Extents>(0,
>> >>> rank()), std::numeric_limits<Index>::max());
>> >>> static_assert(__dyn_reminder > 0);
>> >>> However, with __dyn_reminder value, the precondition
>> >>> https://eel.is/c++draft/mdspan.layout#left.cons-1,
>> >>> can be checked by doing equivalent of __div_remainder for
>> __dyn_extents
>> >>> with __val being __dyn_reminder.
>> >>>
>> >>>
>> >>>> +
>> >>>> + template<typename _Extents>
>> >>>> + consteval array<typename _Extents::index_type,
>> _Extents::rank()>
>> >>>> + __static_extents_array()
>> >>>> + {
>> >>>> + array<typename _Extents::index_type, _Extents::rank()>
>> __exts;
>> >>>> + for(size_t __i = 0; __i < _Extents::rank(); ++__i)
>> >>>> + __exts[__i] = _Extents::static_extent(__i);
>> >>>> + return __exts;
>> >>>> + }
>> >>>>
>> >>>
>> >>> Replaced by __static_exts accessor, as described above.
>> >>>
>> >>>
>> >>>> +
>> >>>> + template<typename _Extents, typename _IndexType>
>> >>>> + concept __representable_size = _Extents::rank_dynamic() != 0
>> >>>> + || __is_representable_product<_IndexType>(
>> >>>> + __static_extents_array<_Extents>());
>> >>>> +
>> >>>> + template<typename _Extents>
>> >>>> + concept __layout_extent = __representable_size<
>> >>>> + _Extents, typename _Extents::index_type>;
>> >>>> + }
>> >>>>
>> >>> +
>> >>>> + template<typename _Extents>
>> >>>> + class layout_left::mapping
>> >>>> + {
>> >>>> + static_assert(__mdspan::__layout_extent<_Extents>,
>> >>>> + "The size of extents_type is not representable as
>> index_type.");
>> >>>> + public:
>> >>>> + using extents_type = _Extents;
>> >>>> + using index_type = typename extents_type::index_type;
>> >>>> + using size_type = typename extents_type::size_type;
>> >>>> + using rank_type = typename extents_type::rank_type;
>> >>>> + using layout_type = layout_left;
>> >>>> +
>> >>>> + constexpr
>> >>>> + mapping() noexcept = default;
>> >>>> +
>> >>>> + constexpr
>> >>>> + mapping(const mapping&) noexcept = default;
>> >>>> +
>> >>>> + constexpr
>> >>>> + mapping(const extents_type& __extents) noexcept
>> >>>> + : _M_extents(__extents)
>> >>>> + {
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>> }
>> >>>> +
>> >>>> + template<typename _OExtents>
>> >>>> + requires (is_constructible_v<extents_type, _OExtents>)
>> >>>> + constexpr explicit(!is_convertible_v<_OExtents,
>> extents_type>)
>> >>>> + mapping(const mapping<_OExtents>& __other) noexcept
>> >>>> + : _M_extents(__other.extents())
>> >>>> + {
>> >>>
>> >>> Here we could do checks at compile time:
>> >>> if constexpr(_OExtents::rank_dynamic() == 0)
>> >>> static_assert( __div_remainder(...) > 0);
>> >>> }
>> >>>
>> >>>
>> >>>> }
>> >>>> +
>> >>>> + constexpr mapping&
>> >>>> + operator=(const mapping&) noexcept = default;
>> >>>> +
>> >>>> + constexpr const extents_type&
>> >>>> + extents() const noexcept { return _M_extents; }
>> >>>> +
>> >>>> + constexpr index_type
>> >>>> + required_span_size() const noexcept
>> >>>> + { return __mdspan::__fwd_prod(_M_extents, _M_extents.rank());
>> }
>> >>>> +
>> >>>> + template<__mdspan::__valid_index_type<index_type>... _Indices>
>> >>>>
>> >>> // Because we extracted rank0 and rank1 specializations
>> >>>
>> >>>> + requires (sizeof...(_Indices) + 1 == extents_type::rank())
>> >>>> + constexpr index_type
>> >>>> + operator()(index_type __idx, _Indices... __indices) const
>> >> noexcept
>> >>>> + {
>> >>>>
>> >>> This could be implemented as, please synchronize the names.
>> >>> if constexpr (!is_same_v<_Indices, index_type> || ...)
>> >>> // Reduce the number of instantations.
>> >>> return operator()(index_type _idx0,
>> >>> static_cast<index_type>(std::move(__indices))....);
>> >>> else
>> >>> {
>> >>> // This can be used for layout stride, if you start with
>> __res =
>> >> 0;
>> >>> index_type __res = _idx0;
>> >>> index_type __mult = _M_extents.extent(0);
>> >>> auto __update = [&__res, &__mult, __pos = 1u](index_type
>> __idx)
>> >>> mutable
>> >>> {
>> >>> __res += __idx * __mult;
>> >>> __mult *= _M_extents.extent(__pos);
>> >>> ++__pos;
>> >>> };
>> >>> // Fold over invocation of lambda
>> >>> (__update(_Indices), ....);
>> >>> return __res;
>> >>> }
>> >>>
>> >>> This could be even simpler and written as (use for layout stride):
>> >>> size_t __pos = 0;
>> >>> return (index_type(0) + ... + __indices * stride(__pos++));
>> >>> Here, I prefer to avoid multiplying multiple times.
>> >>>
>> >>>
>> >>> + return __mdspan::__linear_index_left(
>> >>>> + _M_extents, static_cast<index_type>(__indices)...);
>> >>>> + }
>> >>>> +
>> >>>> + static constexpr bool
>> >>>> + is_always_unique() noexcept { return true; }
>> >>>> +
>> >>>> + static constexpr bool
>> >>>> + is_always_exhaustive() noexcept { return true; }
>> >>>> +
>> >>>> + static constexpr bool
>> >>>> + is_always_strided() noexcept { return true; }
>> >>>> +
>> >>>> + static constexpr bool
>> >>>> + is_unique() noexcept { return true; }
>> >>>> +
>> >>>> + static constexpr bool
>> >>>> + is_exhaustive() noexcept { return true; }
>> >>>> +
>> >>>> + static constexpr bool
>> >>>> + is_strided() noexcept { return true; }
>> >>>> +
>> >>>> + constexpr index_type
>> >>>> + stride(rank_type __i) const noexcept
>> >>>> + requires (extents_type::rank() > 0)
>> >>>> + {
>> >>>> + __glibcxx_assert(__i < extents_type::rank());
>> >>>> + return __mdspan::__fwd_prod(_M_extents, __i);
>> >>>> + }
>> >>>> +
>> >>>> + template<typename _OExtents>
>> >>>> + requires (extents_type::rank() == _OExtents::rank())
>> >>>> + friend constexpr bool
>> >>>> + operator==(const mapping& __self, const mapping<_OExtents>&
>> >>>> __other)
>> >>>> + noexcept
>> >>>> + { return __self.extents() == __other.extents(); }
>> >>>> +
>> >>>> + private:
>> >>>> + [[no_unique_address]] extents_type _M_extents;
>> >>>> + };
>> >>>> +
>> >>>> _GLIBCXX_END_NAMESPACE_VERSION
>> >>>> }
>> >>>> #endif
>> >>>> --
>> >>>> 2.49.0
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >
>>
>>
