C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Why [expr.ref] says that E1->E2 is converted to (*(E1)).E2

From: Sean Mayard <seanmayard_at_[hidden]>
Date: Wed, 10 May 2023 10:36:04 +0530
>
> In terms of syntax and *evaluation order*, yes (as [expr.pre] says).


 Okay so does this mean that the sentence quoted below from [expr.ref#1]
<https://timsong-cpp.github.io/cppwp/n4868/expr.compound#expr.ref-1> also
applies to overloaded operators since it talks about "evaluation"?

*The postfix expression before the dot or arrow is evaluated;63 the result
> of that evaluation, together with the id-expression, determines the result
> of the entire postfix expression.*
>

That is, I want to know if the above quoted sentence from expr.ref#1
<https://timsong-cpp.github.io/cppwp/n4868/expr.compound#expr.ref-1>
applies to overloaded operators since it talks about "evaluation" and
[expr.pre] said that *Overloaded operators obey the rules for syntax and
evaluation order specified in [expr.compound].*

On Tue, 9 May 2023 at 22:30, Sean Mayard <seanmayard_at_[hidden]> wrote:

> Okay for discussion like questions I will mail my future questions to the
> stddiscussion mailing list. Thanks for the info.
>
> On Tue, 9 May 2023, 22:27 Brian Bi, <bbi5291_at_[hidden]> wrote:
>
>> First, please note that you have sent your question to the wrong list.
>> You should use std-discussion_at_[hidden] to ask questions about
>> the standard. std-proposals_at_[hidden] is for, well, proposals,
>> but you should keep in mind that its utility is limited, because the set of
>> people who read it is not representative of the set of people who will
>> actually vote on a formal proposal if you were to submit it for
>> consideration in a committee mailing.
>>
>> On Tue, May 9, 2023 at 12:25 PM Sean Mayard via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> @jonathan
>>>
>>> [expr.pre] also says *Overloaded operators obey the rules for syntax
>>> and evaluation order specified in* [expr.compound]
>>> <https://timsong-cpp.github.io/cppwp/n4868/expr.compound>...
>>>
>>> So even though [expr.compound] is for built in types, [expr.compound]
>>> also applies to overloaded operators?
>>>
>>
>> In terms of syntax and evaluation order, yes (as [expr.pre] says). In
>> terms of semantics, no.
>>
>>
>>>
>>> On Tue, 9 May 2023, 21:36 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>>>
>>>>
>>>>
>>>> On Tue, 9 May 2023 at 15:42, Sean Mayard <seanmayard_at_[hidden]> wrote:
>>>>
>>>>> Look at the previous sentence.
>>>>>
>>>>>
>>>>> Okay, so the previous sentence says "For the first option (dot) the
>>>>> first expression shall be a glvalue.
>>>>> <https://timsong-cpp.github.io/cppwp/n4868/expr.ref#2.sentence-1> For
>>>>> the second option (arrow) the first expression shall be a prvalue having *pointer
>>>>> type*.
>>>>> <https://timsong-cpp.github.io/cppwp/n4868/expr.ref#2.sentence-2> "
>>>>> By pointer type they mean built-in pointer type and not smart pointer type.
>>>>>
>>>>
>>>> Yes, smart pointers have class type. There are no "smart pointer types"
>>>> in the type taxonomy of C++, that's just an idiomatic name for class types
>>>> with a pointer-like API.
>>>>
>>>> But it's irrelevant, [expr.pre] means the whole paragraph only applies
>>>> to the built-in operator, not an overloaded operator. There are no built-in
>>>> -> operators for smart pointer types, only operator->() overloads.
>>>>
>>>>
>>>>
>>>>
>>>>> On Tue, 9 May 2023 at 18:35, Jonathan Wakely <cxx_at_[hidden]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 9 May 2023 at 13:10, Sean Mayard via Std-Proposals <
>>>>>> std-proposals_at_[hidden]> wrote:
>>>>>>
>>>>>>> I read [expr.ref#2] which includes the following sentence:
>>>>>>>
>>>>>>> > *The expression E1->E2 is converted to the equivalent form
>>>>>>> (*(E1)).E2*
>>>>>>>
>>>>>>> My question is, does this mean that "every" expression that has the
>>>>>>> form *E1->E2* will be converted to *(*(E1)).E2. *I mean it is not
>>>>>>> clear to me in what situations/contexts does the above sentence hold?
>>>>>>>
>>>>>>> For example, suppose we have a class that overloads *operator* *but
>>>>>>> does not overload *operator->* then if we use *operator-> *with an
>>>>>>> object of that class type, then that expression will be first converted to
>>>>>>> *(*(E1)).E2* form?
>>>>>>>
>>>>>>> #include <iostream> struct A { int foo = 1, bar =2;};struct B { A a{}; A& operator* () { return a; }}; int main(){ B b{}; int x = b->foo; //i know this will give error because there is no overloaded operator-> //but according to [expr.ref#2] shouldn't b->foo be first converted to (*(b)).foo //and then the overloaded operator* should be used }
>>>>>>>
>>>>>>>
>>>>>>> As you can see in the above program, `b->foo;` gives an error
>>>>>>> because the class `B` has not overloaded *operator-> *. But
>>>>>>> according to [expr.ref#2] the expression *b->foo *should be
>>>>>>> converted to *(*(b)).foo *and then the *operator* *could be used.
>>>>>>>
>>>>>>> So I want to know what exactly does [expr.ref#2] mean when it said " *The
>>>>>>> expression E1->E2 is converted to the equivalent form (*(E1)).E2*
>>>>>>> ". Does this conversion supposed to happen only after `E1->E2` is valid or
>>>>>>> before. Is a CWG issue required for this or I just did not read/interpret
>>>>>>> it correctly.
>>>>>>>
>>>>>>
>>>>>> See [expr.pre] which explains that the rules in Clause [expr] apply
>>>>>> to the built-in operators, not to overloaded operators.
>>>>>>
>>>>>> "Subclause 7.6 defines the effects of operators when applied to types
>>>>>> for which they have not been overloaded." (and also the note before that).
>>>>>>
>>>>>>
>>>>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
>>
>> --
>> *Brian Bi*
>>
>

Received on 2023-05-10 05:06:16