[Dwarf-Discuss] Inconsistency of C++ member function qualifiers

[David Blaikie]

On Tue, Oct 5, 2021 at 1:13 PM <paul.robinson at sony.com> wrote:

> According to https://en.cppreference.com/w/cpp/language/function the
> cv-qualifier is allowed only on non-static member functions, which are
> exactly the ones that have an implicit this-pointer parameter.
>
> *cv*
>
> -
>
> const/volatile qualification, only allowed in non-static member function
> declarations
>
> Are cv-qualified free functions or static member functions a GCC
> extension?  If so, then doing what GCC does seems like exactly the right
> thing to do.  It falls within the ?permissive? nature of DWARF to do that.
> I don?t know that the DWARF standard should say anything special about it,
> though.
>

Ah, sorry, should've clarified earlier - this is only a property of
function types, not of the types of functions... because C++ is fun like
that.

You can't create a free function like "void f() const { }" but you can
create a function type, used for instance in a template type argument which
has a const qualifier: template<typename T> void f1(); ... f1<void ()
const>(); - you can't even create a function pointer of this const
qualified function type: "void (*)() const" is not a valid type, for
instance.

See for instance this C++ standards proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0288r4.html#Specification
- which uses a std::function-like template, but with the const qualifier on
the function type parameter to determine whether the functor is mutable or
not. (so "std::any_invocable<void()>" is only callable when the object is
non-const, but "std::any_invocable<void()const>" is callable even on if
it's a const object)


> --paulr
>
>
>
> *From:* Dwarf-Discuss <dwarf-discuss-bounces at lists.dwarfstd.org> *On
> Behalf Of *David Blaikie via Dwarf-Discuss
> *Sent:* Tuesday, October 5, 2021 3:12 PM
> *To:* DWARF Discuss <dwarf-discuss at lists.dwarfstd.org>
> *Subject:* [Dwarf-Discuss] Inconsistency of C++ member function qualifiers
>
>
>
> C++ member functions can be qualified in a number of ways - classic CV
> (const and volatile) qualifiers, and since C++11, lvalue (&) and rvalue
> (&&) reference qualifiers. Details here:
> https://en.cppreference.com/w/cpp/language/member_functions
> <https://urldefense.com/v3/__https:/en.cppreference.com/w/cpp/language/member_functions__;!!JmoZiZGBv3RvKRSx!tqhSDxClelx78nUz9oi9l27R5fYiWC6bR-gPJvMTM8FbJ-K2FSVDb2wi9pRr3rfbCg$>
>
> A note on 5.10, page 127 says:
>
> "C++ const-volatile qualifiers are encoded as part of the type of the
> ?this?-pointer. C++11 reference and rvalue-reference qualifiers are encoded
> using the DW_AT_reference and DW_AT_rvalue_reference attributes,
> respectively. See also Section 5.7.8 on page 120."
>
> Though this appears to be inadequate, because C++ allows these qualifiers
> on any function type - even one without a first parameter necessary to
> carry the const/volatile qualifiers.
>
> eg:
> template<typename T>
> struct t1 { };
>
> t1<void () const> v1;
>
> GCC implements this type by using DW_TAG_const_type around a
> DW_TAG_subroutine_type. I've implemented the same behavior in Clang
> recently.
>
> For actual member functions (eg: void (some_type::*)() const) both Clang
> and GCC put the const type on the artificial first parameter rather than by
> wrapping the type in DW_TAG_const_type.
>
>
> Does this seem acceptable, should we do something different to unify the
> representation between these two cases? Should we add some more
> non-normative text in 5.10/p127?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20211005/a671089e/attachment.html>