C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Contradiction about this parameter in the C++ standard

From: Edward Catmur <ecatmur_at_[hidden]>
Date: Tue, 19 Apr 2022 10:57:14 +0100
On Tue, 19 Apr 2022 at 09:46, <language.lawyer_at_[hidden]> wrote:

> On 19/04/2022 11:24, Edward Catmur wrote:
> > On Tue, 19 Apr 2022 at 08:57, <language.lawyer_at_[hidden]> wrote:
> >
> >> On 19/04/2022 10:37, Edward Catmur wrote:
> >>> On Tue, 19 Apr 2022 at 03:22, <language.lawyer_at_[hidden]> wrote:
> >>>
> >>>> On 18/04/2022 23:23, Edward Catmur wrote:
> >>>>> On Mon, 18 Apr 2022 at 21:13, <language.lawyer_at_[hidden]> wrote:
> >>>>>
> >>>>>> On 18/04/2022 22:57, Edward Catmur wrote:
> >>>>>>> I suppose that paragraph <
> >>>> https://eel.is/c++draft/expr.call#7.sentence-4>
> >>>>>> (and
> >>>>>>> the following Note) should be struck entirely.
> >>>>>> I'd say then we will not know which object [expr.prim.this]/1 speaks
> >>>> about
> >>>>>> («The keyword `this` names a pointer to the object for which an
> >> implicit
> >>>>>> object member function is invoked»)
> >>>>>>
> >>>>>
> >>>>> "the object for which an implicit object member function is invoked"
> >>>> seems
> >>>>> clear enough; per [expr.call]/2 it's the object expression on the LHS
> >> of
> >>>>> the postfix expression (before the '.', '->', '.*' or '->*').
> >>>>
> >>>> If it is a base-class function, the object is the corresponding base
> >> class
> >>>> subobject, isn't it?
> >>>>
> >>>
> >>> Yes, but that's a problem with [expr.prim.this]/1; you can't have a
> >> pointer
> >>> of base type pointing to an object of derived type. So that subclause
> is
> >>> also defective, and should have appended ", or to its base class
> >> subobject,
> >>> as appropriate".
> >>
> >> I don't understand where the defect is.
> >> When «the object for which function is invoked» is a base class
> subobject
> >> (and it is pointed to by `this`), there is no discrepancy between the
> type
> >> of `this` and the object's type.
> >> «The object for which function is invoked» does not have to be «the
> result
> >> of the object expression».
> >>
> >
> > If it isn't (and is the base class subobject), where is that specified?
> Or
> > where should it be specified?
>
> [expr.call]/7 tries to specify this.
> https://github.com/cplusplus/draft/pull/5399
>
> >> As for [expr.call]/7, there's no need to specify *how* the
> implementation
> >>> is expected to come up with the value of the `this` pointer (although
> it
> >>> could be a Note).
> >>
> >> When you say that [expc.call]/2 defines the object for which the
> function
> >> is invoked, do you mean «the call is as a member of the class object
> >> referred to by the object expression»?
> >>
> >
> > Yes, I think that's where the connection is made. So that's possibly a
> > derived class object, and it's worth explaining where the this pointer
> with
> > type pointer to base gets its value from.
>
> IDK, why/when having «the object for which function is invoked» meaning
> «the result of the object expression» and overloading the definition of
> `this` with «or to its base class subobject» is useful?
>

What else could "the object for which function the is invoked" mean other
than "the result of the object expression"?

Received on 2022-04-19 09:57:25