On Wed, 10 Sept 2025 at 11:08, Luc Grosheintz <luc.groshei...@gmail.com> wrote:
>
>
>
> On 9/10/25 11:24 AM, Jonathan Wakely wrote:
> > On Wed, 10 Sept 2025 at 09:44, Jonathan Wakely <jwak...@redhat.com> wrote:
> >>
> >> On Wed, 10 Sept 2025 at 07:49, Luc Grosheintz <luc.groshei...@gmail.com>
> >> wrote:
> >>>
> >>> In libstdc++ the prefix _S is used for static members only. In <mdspan>
> >>> there's several type aliases that also used the prefix _S. They now use
> >>> double underscore instead.
> >>
> >> Thanks for revisiting these.
> >>
> >>>
> >>> libstdc++-v3/ChangeLog:
> >>>
> >>> * include/std/mdspan (_ExtentsStorage::__base): New name for
> >>> _S_base.
> >>> (_ExtentsStorage::__storage_type): New name for _S_storage.
> >>> (extents::__storage_type): New name for _S_storage.
> >>> (layout_stride::mapping::__strides_type): New name for
> >>> _S_stries_t.
> >>> * testsuite/23_containers/mdspan/class_mandate_neg.cc: Update
> >>> test to the new error message.
> >>>
> >>> Signed-off-by: Luc Grosheintz <luc.groshei...@gmail.com>
> >>> ---
> >>> libstdc++-v3/include/std/mdspan | 33 ++++++++++---------
> >>> .../23_containers/mdspan/class_mandate_neg.cc | 2 +-
> >>> 2 files changed, 18 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/libstdc++-v3/include/std/mdspan
> >>> b/libstdc++-v3/include/std/mdspan
> >>> index 678b2619ebe..f0139a95b11 100644
> >>> --- a/libstdc++-v3/include/std/mdspan
> >>> +++ b/libstdc++-v3/include/std/mdspan
> >>> @@ -148,14 +148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >>> class _ExtentsStorage : public _StaticExtents<_Extents>
> >>> {
> >>> private:
> >>> - using _S_base = _StaticExtents<_Extents>;
> >>> + using __base = _StaticExtents<_Extents>;
> >>
> >> Looking through the other headers, we usually use _Base for this case,
> >> and for other typedefs that are private to the class (and its
> >> friends).
>
> I'll redo them all (seems odd to only do half).
>
> >>
> >> Yes, that's inconsistent with __type that we use in some internal type
> >> traits, but in those cases __type is public and we intend it to be
> >> used from outside the class, by code using it. e.g. constant_wrapper
> >> uses _CwFixedValue::__type.
> >
> > I should make some updates to
> > https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html
> > to cover this.
> >
> > And turn that numbered list into a proper DocBook <variablelist>, and
> > remove number 10 (about prefixing members with 'this->' because of
> > Koenig lookup, which is just wrong).
> >
>
> I'd like to suggest the following for the long example:
>
> - add a using _SomeType = ...; (or _Some_type),
> - an example of attributes like [[nodiscard]] (I think it's on its
> own line),
> - an example with requires,
>
> - an example of trailing return type (-> ret_type): once for when
> it doesn't have to break and once where it wont fit.
Good idea. Nobody has touched those examples for at least 15 years, so
they predate C++11.
>
> Here's some things I'm not fully convinced are correct:
> - in the example I think the
> if (test)
> {
> nested code
> }
> is wrong because we need to indent the braces by one level.
>
> - double check the for-loop, if we put the { on the same line,
> I need to do some fixups for <mdspan>.
>
> - In
> function_name(char* pointer, // "char *pointer" is wrong.
> char* argument,
> const Reference& ref)
>
> I think we're expected to squash as much onto one line as we can?
> function_name(char* pointer, char* argument, // not: char *pointer
> const Reference& ref)
>
> - // In-class function definitions should be restricted to
> // one-liners.
>
> I'm seeing lots of violation of that rule.
Agreed on all counts.
> I remember liking and referring back to the example a lot in the
> beginning.
It's useful, but would be a lot better if it reflected our actual
coding style ;-)
