Comma Operator - Left to Right Associativity

[AJ D via Gcc]

Isn't comma operator suppose to honor left-to-right associativity?

When I try it on this test case, it exhibits right-to-left associativity.

#include 



struct CBI;

struct EC;

struct CET;



struct CBI {

CBI& operator,(const CBI& rhs)

{ return *const_cast(&rhs); }

};



struct EC : CBI {

explicit EC(CET* cet) : cet_(cet)

{}



CET* cet_;

};



struct CET {

CBI& operator,(const CBI& rhs) const

{ return *const_cast(&rhs); }



operator EC&() const

{ return *new EC(const_cast(this)); }

};



static const CET&

hello() {

std::cout << "Hello " << std::endl;

return *new CET();

}



static const CET&

world() {

std::cout << "World " << std::endl;

return *new CET();

}



static void

test_comma_operator(CBI&) {



}



int main()

{

test_comma_operator ((

hello(),

world()

));

}



CLANG appears to do it right.


us01odcvde08782> clang++ -g test.cpp

us01odcvde08782> ./a.out

*Hello*

World

us01odcvde08782> g++ -g test.cpp

us01odcvde08782> ./a.out

World

*Hello*

us01odcvde08782>


I was using CentOS6.8 with gcc 6.2. However, trying other versions of GCC
didn't make any difference.


Is this a bug in GCC?

Re: Comma Operator - Left to Right Associativity

[David Brown]

On 04/02/2021 21:08, AJ D via Gcc wrote:
> Isn't comma operator suppose to honor left-to-right associativity?
> 
> When I try it on this test case, it exhibits right-to-left associativity.

You are not talking about associativity - you are talking about
evaluation order.  (The two things are often mixed up.)

For the built-in comma operator, you get guaranteed order of evaluation
(or more precisely, guaranteed order of visible side-effects).  But for
a user-defined comma operator, you do not - until C++17, which has
guaranteed evaluation ordering in some circumstances.

See  (it's
easier to read than the C++ standards).

Try your test again with "-std=c++17" or "-std=g++17" - if the order is
still reversed, it's a gcc bug (AFAICS).  But for standards prior to
C++17, the ordering is unspecified for user-defined comma operators.

This is not unlike the difference between the built-in logic operators
&& and ||, which are guaranteed short-circuiting, while user-defined
overloads are not.  And for arithmetic operators, you don't get integer
promotion, automatic conversion to a common type, etc.

Basically, the user-defined operators are just syntactic sugar for a
function call - they don't have the "magic" features of the real operators.

David

Re: Comma Operator - Left to Right Associativity

[Andreas Schwab]

On Feb 04 2021, David Brown wrote:

> For the built-in comma operator, you get guaranteed order of evaluation
> (or more precisely, guaranteed order of visible side-effects).  But for
> a user-defined comma operator, you do not - until C++17, which has
> guaranteed evaluation ordering in some circumstances.

But not the evaluation order of function arguments.  See
 Sequenced-before
rules, rule 15.

> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
> still reversed, it's a gcc bug (AFAICS).

I don't think so.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Comma Operator - Left to Right Associativity

[David Brown]

On 04/02/2021 22:21, Andreas Schwab wrote:
> On Feb 04 2021, David Brown wrote:
> 
>> For the built-in comma operator, you get guaranteed order of evaluation
>> (or more precisely, guaranteed order of visible side-effects).  But for
>> a user-defined comma operator, you do not - until C++17, which has
>> guaranteed evaluation ordering in some circumstances.
> 
> But not the evaluation order of function arguments.  See
>  Sequenced-before
> rules, rule 15.

Correct.

> 
>> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
>> still reversed, it's a gcc bug (AFAICS).
> 
> I don't think so.
> 

Unless I am missing something, in the OP's program it is a user-defined
comma operator that is called.  There is only one argument to the
"test_comma_operator" function, the result of that user-defined comma
operator.  So rule 15 above does not apply - rule 16 applies.

At least that is /my/ reading of the cppreference page and the OP's program.

David

gcc-8-20210204 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20210204 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20210204/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 67620b038d9746e2ebf274548cd9de0d853ba909

You'll find:

 gcc-8-20210204.tar.xzComplete GCC

  SHA256=1eed7af357605081e70828007eb81aa9fcb7a5aae8401e94cac72e916955907d
  SHA1=52e266a9768ad94df5793e0e31b49b2b51e04a7c

Diffs from 8-20210128 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Comma Operator - Left to Right Associativity

[AJ D via Gcc]

Nope, -std=c++17 didn’t help either.

On Thu, Feb 4, 2021 at 1:33 PM David Brown  wrote:

>
>
> On 04/02/2021 22:21, Andreas Schwab wrote:
> > On Feb 04 2021, David Brown wrote:
> >
> >> For the built-in comma operator, you get guaranteed order of evaluation
> >> (or more precisely, guaranteed order of visible side-effects).  But for
> >> a user-defined comma operator, you do not - until C++17, which has
> >> guaranteed evaluation ordering in some circumstances.
> >
> > But not the evaluation order of function arguments.  See
> >  Sequenced-before
> > rules, rule 15.
>
> Correct.
>
> >
> >> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
> >> still reversed, it's a gcc bug (AFAICS).
> >
> > I don't think so.
> >
>
> Unless I am missing something, in the OP's program it is a user-defined
> comma operator that is called.  There is only one argument to the
> "test_comma_operator" function, the result of that user-defined comma
> operator.  So rule 15 above does not apply - rule 16 applies.
>
> At least that is /my/ reading of the cppreference page and the OP's
> program.
>
> David
>
>

Re: Comma Operator - Left to Right Associativity

[AJ D via Gcc]

Yes, there is only function argument which is the result of the comma
operator.

On Thu, Feb 4, 2021 at 2:46 PM AJ D  wrote:

> Nope, -std=c++17 didn’t help either.
>
> On Thu, Feb 4, 2021 at 1:33 PM David Brown 
> wrote:
>
>>
>>
>> On 04/02/2021 22:21, Andreas Schwab wrote:
>> > On Feb 04 2021, David Brown wrote:
>> >
>> >> For the built-in comma operator, you get guaranteed order of evaluation
>> >> (or more precisely, guaranteed order of visible side-effects).  But for
>> >> a user-defined comma operator, you do not - until C++17, which has
>> >> guaranteed evaluation ordering in some circumstances.
>> >
>> > But not the evaluation order of function arguments.  See
>> > 
>> Sequenced-before
>> > rules, rule 15.
>>
>> Correct.
>>
>> >
>> >> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
>> >> still reversed, it's a gcc bug (AFAICS).
>> >
>> > I don't think so.
>> >
>>
>> Unless I am missing something, in the OP's program it is a user-defined
>> comma operator that is called.  There is only one argument to the
>> "test_comma_operator" function, the result of that user-defined comma
>> operator.  So rule 15 above does not apply - rule 16 applies.
>>
>> At least that is /my/ reading of the cppreference page and the OP's
>> program.
>>
>> David
>>
>>