Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #83406 > unrolled thread

GCC hasn't even gotten around to sequencing argument evaluation yet???

Back to article view | Back to comp.lang.c++

Contents

  GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-01 20:34 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-02 10:19 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Bo Persson <bo@bo-persson.se> - 2022-04-02 12:19 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-02 14:18 +0200
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Gollwitzer <auriocus@gmx.de> - 2022-04-02 12:30 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-02 14:12 +0200
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-02 14:20 +0200
        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-02 14:28 +0000
          Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-02 17:27 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-02 15:39 +0000
              Re: GCC hasn't even gotten around to sequencing argument evaluation Barry Schwarz <schwarzb@delq.com> - 2022-04-02 09:15 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 08:21 +0000
                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 12:02 +0200
                    Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 14:42 +0000
                      Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-04 08:49 -0700
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:18 +0000
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 08:37 -0700
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:54 +0000
                              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-06 11:24 +0200
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Juha Nieminen <nospam@thanks.invalid> - 2022-04-06 10:49 +0000
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-06 18:21 +0200
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-04-06 15:40 +0100
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-06 15:00 +0000
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-04-06 17:03 +0100
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-04-06 17:18 +0100
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-07 08:58 +0000
                                        Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-07 11:01 -0400
                                Re: GCC hasn't even gotten around to sequencing argument evaluation "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-06 23:13 +0200
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-07 09:11 +0200
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-06 10:53 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-06 14:50 -0400
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Sams Lara <samlara622@gmail.com> - 2022-04-06 22:27 +0100
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-06 14:51 -0700
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation Sams Lara <samlara622@gmail.com> - 2022-04-06 22:59 +0100
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-06 15:54 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation Öö Tiib <ootiib@hot.ee> - 2022-04-06 15:11 -0700
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-09 09:38 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-06 23:48 -0400
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-06 18:39 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-06 23:49 -0400
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-05 08:55 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 10:23 -0700
                          Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-05 14:36 -0400
                      Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-04 12:27 -0400
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:21 +0000
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 08:41 -0700
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:50 +0000
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 10:19 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-05 14:33 -0400
                          Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-05 14:28 -0400
                      Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 18:29 +0200
              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 11:27 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 08:23 +0000
                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 12:15 +0200
                    Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 14:43 +0000
                      Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 18:34 +0200
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:23 +0000
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 08:38 -0700
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:49 +0000
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-05 11:31 -0700
                                Re: GCC hasn't even gotten around to sequencing argument evaluation scott@slp53.sl.home (Scott Lurndal) - 2022-04-05 22:45 +0000
              Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-02 23:34 -0400
                Re: GCC hasn't even gotten around to sequencing argument evaluation Manfred <noname@add.invalid> - 2022-04-03 17:43 +0200
                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-03 15:40 -0400
                Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 08:24 +0000
                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-04 12:01 -0400
              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-03 13:02 +0200
                Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 04:46 -0700
                  Re: GCC hasn't even gotten around to sequencing argument evaluation Öö Tiib <ootiib@hot.ee> - 2022-04-03 07:02 -0700
                    Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 11:30 -0700
                      Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-03 21:20 +0200
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 12:49 -0700
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-04 00:40 +0300
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 15:40 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 09:13 +0200
                          Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 09:02 +0200
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-04 02:07 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 13:28 +0200
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-04 06:01 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 19:11 +0200
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation scott@slp53.sl.home (Scott Lurndal) - 2022-04-04 17:59 +0000
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-05 06:55 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation Manfred <noname@add.invalid> - 2022-04-03 18:39 +0200
          Re: GCC hasn't even gotten around to sequencing argument evaluation Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-03 09:09 +0300
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@add.invalid> - 2022-04-02 19:53 +0200
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-03 13:45 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@add.invalid> - 2022-04-03 17:27 +0200
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-02 21:17 +0100
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@invalid.add> - 2022-04-02 23:04 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-03 00:22 +0100
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 17:33 -0700
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-03 14:23 +0100
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-06 08:31 -0700
              Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-06 11:05 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 03:32 -0700
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 11:18 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-02 13:11 +0200
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manu Raju <MR@invalid.invalid> - 2022-04-02 18:26 +0100
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manu Raju <MR@invalid.invalid> - 2022-04-02 21:46 +0100
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 17:35 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Language Lawyer <language.lawyer@gmail.com> - 2022-04-04 02:28 -0700
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-04 05:52 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Language Lawyer <language.lawyer@gmail.com> - 2022-06-21 03:36 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Juha Nieminen <nospam@thanks.invalid> - 2022-04-04 10:48 +0000
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-04 05:49 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Juha Nieminen <nospam@thanks.invalid> - 2022-04-05 06:34 +0000
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-05 10:20 +0100
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 07:51 -0700
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@add.invalid> - 2022-04-05 17:53 +0200
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 06:06 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-09 21:20 -0700
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-09 21:39 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-09 22:34 -0700
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 09:19 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-10 12:21 +0200
              Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 12:47 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-11 12:18 -0700
              Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-11 12:33 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 09:20 +0200
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-11 12:32 -0700
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-11 15:11 -0700

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#83454

On Saturday, 2 April 2022 at 06:35:16 UTC+3, Andrey Tarasevich wrote:
> #include <iostream> 
> 
> int foo(int a, int b) 
> { 
> return a + b; 
> } 
> 
> int main() 
> { 
> int i = 1; 
> int r = foo(++i, ++i); 
> std::cout << r << std::endl; 
> } 
> 
> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding 
> sequencing to argument evaluation, albeit indeterminate, is a major and 
> a very important change in C++17. How come it is still not implemented 
> in GCC? What are they waiting for? Is there some sort of intentional 
> opposition to that change in the standard? 
> 
> Clang produces the correct 5, but warns about "unsequenced evaluation". 
> The warning is nonsensical, but at least they got the result right. This 
> - a nonsensical warning accompanied by a correct result - is usually the 
> case for all new C++ sequencing rules in Clang. 
> 
> MSVC++ quietly produces the correct 5. 

There is an alternative opinion on what C++17 has changed in the argument evaluation order
https://stackoverflow.com/questions/71005600/are-function-arguments-not-evaluated-left-to-right-how-are-side-effects-on-the/71005677#comment125532936_71005677

[toc] | [prev] | [next] | [standalone]

#83460

On 4/4/2022 2:28 AM, Language Lawyer wrote:
> On Saturday, 2 April 2022 at 06:35:16 UTC+3, Andrey Tarasevich wrote:
>> #include <iostream>
>>
>> int foo(int a, int b)
>> {
>> return a + b;
>> }
>>
>> int main()
>> {
>> int i = 1;
>> int r = foo(++i, ++i);
>> std::cout << r << std::endl;
>> }
>>
>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>> sequencing to argument evaluation, albeit indeterminate, is a major and
>> a very important change in C++17. How come it is still not implemented
>> in GCC? What are they waiting for? Is there some sort of intentional
>> opposition to that change in the standard?
>>
>> Clang produces the correct 5, but warns about "unsequenced evaluation".
>> The warning is nonsensical, but at least they got the result right. This
>> - a nonsensical warning accompanied by a correct result - is usually the
>> case for all new C++ sequencing rules in Clang.
>>
>> MSVC++ quietly produces the correct 5.
> 
> There is an alternative opinion on what C++17 has changed in the argument evaluation order
> https://stackoverflow.com/questions/71005600/are-function-arguments-not-evaluated-left-to-right-how-are-side-effects-on-the/71005677#comment125532936_71005677

Where did you find an "alternative opinion" at the link? The answer is 
simply incorrect. Meanwhile, the comments state exactly the same thing 
that we state here. Nothing "alternative" there. What are you talking 
about specifically?

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#84864

On Monday, 4 April 2022 at 17:52:51 UTC+5, Andrey Tarasevich wrote:
> On 4/4/2022 2:28 AM, Language Lawyer wrote: 
> > On Saturday, 2 April 2022 at 06:35:16 UTC+3, Andrey Tarasevich wrote: 
> >> #include <iostream> 
> >> 
> >> int foo(int a, int b) 
> >> { 
> >> return a + b; 
> >> } 
> >> 
> >> int main() 
> >> { 
> >> int i = 1; 
> >> int r = foo(++i, ++i); 
> >> std::cout << r << std::endl; 
> >> } 
> >> 
> >> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding 
> >> sequencing to argument evaluation, albeit indeterminate, is a major and 
> >> a very important change in C++17. How come it is still not implemented 
> >> in GCC? What are they waiting for? Is there some sort of intentional 
> >> opposition to that change in the standard? 
> >> 
> >> Clang produces the correct 5, but warns about "unsequenced evaluation". 
> >> The warning is nonsensical, but at least they got the result right. This 
> >> - a nonsensical warning accompanied by a correct result - is usually the 
> >> case for all new C++ sequencing rules in Clang. 
> >> 
> >> MSVC++ quietly produces the correct 5. 
> > 
> > There is an alternative opinion on what C++17 has changed in the argument evaluation order 
> > https://stackoverflow.com/questions/71005600/are-function-arguments-not-evaluated-left-to-right-how-are-side-effects-on-the/71005677#comment125532936_71005677
> Where did you find an "alternative opinion" at the link? The answer is 
> simply incorrect. Meanwhile, the comments state exactly the same thing 
> that we state here. Nothing "alternative" there. What are you talking 
> about specifically?

I think I've linked a specific comment.
Anyway, https://cplusplus.github.io/CWG/issues/2599.html

[toc] | [prev] | [next] | [standalone]

#83457

Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>     int r = foo(++i, ++i);

As others have pointed out, this seems to be unspecified behavior
(previously undefined behavior). Meaning that the compiler can do
those in whatever order it wants, and pass either the previous or
the next value to the function as it wants.

Even if the order in which the arguments are evaluated were
specified, I don't think C++17 defines what *values* will be
passed to the function (ie. i+1 and i+2, or just i+2 for both).

[toc] | [prev] | [next] | [standalone]

#83459

On 4/4/2022 3:48 AM, Juha Nieminen wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>      int r = foo(++i, ++i);
> 
> As others have pointed out, this seems to be unspecified behavior
> (previously undefined behavior). Meaning that the compiler can do
> those in whatever order it wants, and pass either the previous or
> the next value to the function as it wants.

As it is pointed out by me in my original message, the behavior is 
unspecified. No need to re-point it out.

However, as it is pointed out by me in my original message, regardless 
of which of the unspecified variant is taken, the result is perfectly 
defined and it shall be 5.

This is the essence of the question.

> Even if the order in which the arguments are evaluated were
> specified, I don't think C++17 defines what *values* will be
> passed to the function (ie. i+1 and i+2, or just i+2 for both).

Yes, it does define it.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83471

Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> On 4/4/2022 3:48 AM, Juha Nieminen wrote:
>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>>      int r = foo(++i, ++i);
>> 
>> As others have pointed out, this seems to be unspecified behavior
>> (previously undefined behavior). Meaning that the compiler can do
>> those in whatever order it wants, and pass either the previous or
>> the next value to the function as it wants.
> 
> As it is pointed out by me in my original message, the behavior is 
> unspecified. No need to re-point it out.
> 
> However, as it is pointed out by me in my original message, regardless 
> of which of the unspecified variant is taken, the result is perfectly 
> defined and it shall be 5.

So the behavior is both unspecified and defined?

How does that work?

>> Even if the order in which the arguments are evaluated were
>> specified, I don't think C++17 defines what *values* will be
>> passed to the function (ie. i+1 and i+2, or just i+2 for both).
> 
> Yes, it does define it.

I would be curious to see the exact passage in the standard.

[toc] | [prev] | [next] | [standalone]

#83472

Juha Nieminen <nospam@thanks.invalid> writes:

> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 4/4/2022 3:48 AM, Juha Nieminen wrote:
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>>>      int r = foo(++i, ++i);
>>> 
>>> As others have pointed out, this seems to be unspecified behavior
>>> (previously undefined behavior). Meaning that the compiler can do
>>> those in whatever order it wants, and pass either the previous or
>>> the next value to the function as it wants.
>> 
>> As it is pointed out by me in my original message, the behavior is 
>> unspecified. No need to re-point it out.
>> 
>> However, as it is pointed out by me in my original message, regardless 
>> of which of the unspecified variant is taken, the result is perfectly 
>> defined and it shall be 5.
>
> So the behavior is both unspecified and defined?
>
> How does that work?

AT is talking about the result of the function call.  The behaviour of
the program  be unspecified (one of two possible orders of evaluation
will be used) but the result from f will be the same (and hence fully
defined) in both cases.

>>> Even if the order in which the arguments are evaluated were
>>> specified, I don't think C++17 defines what *values* will be
>>> passed to the function (ie. i+1 and i+2, or just i+2 for both).
>> 
>> Yes, it does define it.
>
> I would be curious to see the exact passage in the standard.

The key part is in 8.5.1.2 "Function call" paragraph 5:

  "The initialization of a parameter, including every associated value
  computation and side effect, is indeterminately sequenced with respect
  to that of any other parameter."

so in

  extern foo(int a, int b);
  int i = 1;
  int r = foo(++i, ++i);

either the first argument will be 2 and the second 3, or the first will
be 3 and the second 2.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#83474

On 4/4/2022 11:34 PM, Juha Nieminen wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 4/4/2022 3:48 AM, Juha Nieminen wrote:
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>>>       int r = foo(++i, ++i);
>>>
>>> As others have pointed out, this seems to be unspecified behavior
>>> (previously undefined behavior). Meaning that the compiler can do
>>> those in whatever order it wants, and pass either the previous or
>>> the next value to the function as it wants.
>>
>> As it is pointed out by me in my original message, the behavior is
>> unspecified. No need to re-point it out.
>>
>> However, as it is pointed out by me in my original message, regardless
>> of which of the unspecified variant is taken, the result is perfectly
>> defined and it shall be 5.
> 
> So the behavior is both unspecified and defined?
> 
> How does that work?

Um... It is not the entire "behavior" that is defined. It is the result 
of `foo` that is defined. That's what I said. Don't mix the two.

It it a perfectly normal situation, when the entire range of unspecified 
behaviors allowed by the standard ultimately converges in the end to the 
same result in some variable. In this case result is the return value of 
`foo` saved into `r`.

My example is deliberately crafted to exhibit this phenomenon.

You seem to have hard time grasping the concept of multiple (or all) 
possible variations of unspecified behavior in a specific context 
leading to perfectly identical outcomes. But, once again, there's 
nothing remarkable about it.

In exactly the same fashion in C++98 (well before C++17) the following 
code exhibits unspecified behavior, yet guarantees the same result in `r`

    int foo(int *&p) { return *p++; }

    int a[] = { 2, 3 }, *p = a;
    int r = foo(p) + foo(p);
    // It is unspecified which invocation of `foo` will be
    // called first. So, we do have "unspecified behavior" here.
    // Yet the language guarantees `5` in `r`

Again, nothing surprising or remarkable in this example. Behavior is 
unspecified. The result in `r` is perfectly defined.

>>> Even if the order in which the arguments are evaluated were
>>> specified, I don't think C++17 defines what *values* will be
>>> passed to the function (ie. i+1 and i+2, or just i+2 for both).
>>
>> Yes, it does define it.
> 
> I would be curious to see the exact passage in the standard.

Passage about what exactly? New rules for sequencing or argument 
evaluation and parameter initialization? The relevant paragraph (and the 
C++17-specific change) has been quoted here already more than once

http://eel.is/c++draft/expr.call#8

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83483

On 4/5/2022 4:51 PM, Andrey Tarasevich wrote:
> On 4/4/2022 11:34 PM, Juha Nieminen wrote:
>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>> On 4/4/2022 3:48 AM, Juha Nieminen wrote:
>>>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>>>>       int r = foo(++i, ++i);
>>>>
>>>> As others have pointed out, this seems to be unspecified behavior
>>>> (previously undefined behavior). Meaning that the compiler can do
>>>> those in whatever order it wants, and pass either the previous or
>>>> the next value to the function as it wants.
>>>
>>> As it is pointed out by me in my original message, the behavior is
>>> unspecified. No need to re-point it out.
>>>
>>> However, as it is pointed out by me in my original message, regardless
>>> of which of the unspecified variant is taken, the result is perfectly
>>> defined and it shall be 5.
>>
>> So the behavior is both unspecified and defined?
>>
>> How does that work?
> 
> Um... It is not the entire "behavior" that is defined. It is the result 
> of `foo` that is defined. That's what I said. Don't mix the two.

I believe that this statement does not clarify much of the issue.

I think it is better to stick to the quote (given by Ben) from the 
standard, where the key point is "indeterminately sequenced".
This means that the two ++i expressions, and the initialization of the 
respective function parameters a and b, /are/ sequenced with respect to 
each other. This behaviour is defined.
Now, what is left indeterminate by the standard is whether the first 
parameter is evaluated and initialized before the second one, or the 
other way around.
This leaves the implementation free to choose between two different 
behaviours, yet it mandates that the behaviour is defined as one of the 
two. The implementation is /not/ allowed to treat the code as "undefined 
behaviour", which would mean that the standard would give no guarantee 
at all on any behaviour for the code.

The fact that in your example foo() yields the same result for both of 
the allowed possible behaviours, is irrelevant to this discussion. The 
code would still be valid, and the behaviour would still be defined, if 
the function returned a-b instead of a+b.

Now, the question arises of which is the correct result in case foo() 
returned a-b. The answer is that both +1 and -1 would be correct results 
as far as the standard is concerned. Yet, a conforming implementation is 
not allowed to show any other behaviour than these two results.

At this point, obviously the programmer still wants to know univocally 
which is the expected result. A univocal answer to this point does not 
come from the standard (this is the "indeterminate" part), so either it 
comes from the specification of the implementation in use, or the 
programmer needs to modify the code in order to explicitly define a 
sequence order for the values of a and b.

After all, your example is intentionally convoluted, so this last bit 
should not come as a surprise.

<snip>

[toc] | [prev] | [next] | [standalone]

#83553

Am 02.04.2022 um 05:34 schrieb Andrey Tarasevich:
>    #include <iostream>
> 
>    int foo(int a, int b)
>    {
>      return a + b;
>    }
> 
>    int main()
>    {
>      int i = 1;
>      int r = foo(++i, ++i);
>      std::cout << r << std::endl;
>    }
> 
> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? ...

The ++i's are taken ordered from left to right since the
first C version.

[toc] | [prev] | [next] | [standalone]

#83554

On 4/9/2022 9:06 PM, Christian Hanné wrote:
> Am 02.04.2022 um 05:34 schrieb Andrey Tarasevich:
>>    #include <iostream>
>>
>>    int foo(int a, int b)
>>    {
>>      return a + b;
>>    }
>>
>>    int main()
>>    {
>>      int i = 1;
>>      int r = foo(++i, ++i);
>>      std::cout << r << std::endl;
>>    }
>>
>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? ...
> 
> The ++i's are taken ordered from left to right since the
> first C version.

Um... No.

I wonder where you got this nonsense from.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83555

On Sunday, April 10, 2022 at 12:06:23 AM UTC-4, Christian Hanné wrote:
> Am 02.04.2022 um 05:34 schrieb Andrey Tarasevich: 
> >   #include <iostream> 
> > 
> >   int foo(int a, int b) 
> >   { 
> >     return a + b; 
> >   } 
> > 
> >   int main() 
> >   { 
> >     int i = 1; 
> >     int r = foo(++i, ++i); 
> >     std::cout << r << std::endl; 
> >   } 
> > 
> > This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? ... 
> 
> The ++i's are taken ordered from left to right since the 
> first C version.

Citation, please?

My copy of the C90 standard says "The order of evaluation of the
function designator, the arguments, and subexpressions within the
arguments is unspecified, but there is a sequence point before the
actual call." (6.3.2.2).

My copy of "The C Programming Language", 1st edition, says "The
order of evaluation of arguments is undefined by the language; take
note that the various compilers differ." Appendix A, sectiojn 7.1.

How do your sources differ from mine?

[toc] | [prev] | [next] | [standalone]

#83556

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> On Sunday, April 10, 2022 at 12:06:23 AM UTC-4, Christian Hanné wrote:
>> Am 02.04.2022 um 05:34 schrieb Andrey Tarasevich: 
>> >   #include <iostream> 
>> > 
>> >   int foo(int a, int b) 
>> >   { 
>> >     return a + b; 
>> >   } 
>> > 
>> >   int main() 
>> >   { 
>> >     int i = 1; 
>> >     int r = foo(++i, ++i); 
>> >     std::cout << r << std::endl; 
>> >   } 
>> > 
>> > This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? ... 
>> 
>> The ++i's are taken ordered from left to right since the 
>> first C version.
>
> Citation, please?
>
> My copy of the C90 standard says "The order of evaluation of the
> function designator, the arguments, and subexpressions within the
> arguments is unspecified, but there is a sequence point before the
> actual call." (6.3.2.2).
>
> My copy of "The C Programming Language", 1st edition, says "The
> order of evaluation of arguments is undefined by the language; take
> note that the various compilers differ." Appendix A, sectiojn 7.1.
>
> How do your sources differ from mine?

Christian Hanné's sources differ from yours in that you are not a troll.
Christian Hanné has a history of posting deliberate misinformation here.
It's not plausible that he's merely mistaken; his lies indicate that he
knows the truth.

The particular nonsense of his that landed him in my killfile a year and
a half ago was:

    Convertion to uintptr_t involves a privilege-check to the page
    addressed. That's not true for conversions to ptrdiff_t or size_t.

(I presume he thinks he's being clever.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#83557

Am 10.04.2022 um 07:34 schrieb Keith Thompson:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>> On Sunday, April 10, 2022 at 12:06:23 AM UTC-4, Christian Hanné wrote:
>>> Am 02.04.2022 um 05:34 schrieb Andrey Tarasevich:
>>>>    #include <iostream>
>>>>
>>>>    int foo(int a, int b)
>>>>    {
>>>>      return a + b;
>>>>    }
>>>>
>>>>    int main()
>>>>    {
>>>>      int i = 1;
>>>>      int r = foo(++i, ++i);
>>>>      std::cout << r << std::endl;
>>>>    }
>>>>
>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? ...
>>>
>>> The ++i's are taken ordered from left to right since the
>>> first C version.
>>
>> Citation, please?
>>
>> My copy of the C90 standard says "The order of evaluation of the
>> function designator, the arguments, and subexpressions within the
>> arguments is unspecified, but there is a sequence point before the
>> actual call." (6.3.2.2).
>>
>> My copy of "The C Programming Language", 1st edition, says "The
>> order of evaluation of arguments is undefined by the language; take
>> note that the various compilers differ." Appendix A, sectiojn 7.1.
>>
>> How do your sources differ from mine?
> 
> Christian Hanné's sources differ from yours in that you are not a troll.
> Christian Hanné has a history of posting deliberate misinformation here.
> It's not plausible that he's merely mistaken; his lies indicate that he
> knows the truth.
> 
> The particular nonsense of his that landed him in my killfile a year and
> a half ago was:
> 
>      Convertion to uintptr_t involves a privilege-check to the page
>      addressed. That's not true for conversions to ptrdiff_t or size_t.

That's the exact wording from the standard.

[toc] | [prev] | [next] | [standalone]

#83559

On 10/04/2022 09:19, Christian Hanné wrote:
> Am 10.04.2022 um 07:34 schrieb Keith Thompson:
>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

>>> How do your sources differ from mine?
>>
>> Christian Hanné's sources differ from yours in that you are not a troll.
>> Christian Hanné has a history of posting deliberate misinformation here.
>> It's not plausible that he's merely mistaken; his lies indicate that he
>> knows the truth.
>>
>> The particular nonsense of his that landed him in my killfile a year and
>> a half ago was:
>>
>>      Convertion to uintptr_t involves a privilege-check to the page
>>      addressed. That's not true for conversions to ptrdiff_t or size_t.
> 
> That's the exact wording from the standard.
> 

You might be able to fool some people on Stack Overflow with this kind
of nonsense, but the regulars here sleep with the C and C++ standards
under their pillows.  All you are doing is confirming that you are
knowingly and intentionally lying.

Please stop your trolling.  It is pathetic, annoying and anti-social.

(Apologies to Keith and others who have killfiled this person, and hoped
never to hear of him again - but it's important that less knowledgable
people reading this group know that his posts are wrong and designed to
confuse and misinform, and it's important that the knowledgeable and
helpful people know they shouldn't waste time trying to educate him.)

[toc] | [prev] | [next] | [standalone]

#83560

> You might be able to fool some people on Stack Overflow with this kind
> of nonsense, but the regulars here sleep with the C and C++ standards
> under their pillows.  All you are doing is confirming that you are
> knowingly and intentionally lying.

You simply wish the standard says sth. differen than you like.

[toc] | [prev] | [next] | [standalone]

#83567

On Sunday, April 10, 2022 at 3:19:27 AM UTC-4, Christian Hanné wrote:
> Am 10.04.2022 um 07:34 schrieb Keith Thompson: 
...
> > The particular nonsense of his that landed him in my killfile a year and 
> > a half ago was: 
> > 
> > Convertion to uintptr_t involves a privilege-check to the page 
> > addressed. That's not true for conversions to ptrdiff_t or size_t.
> That's the exact wording from the standard.

Citation, please? There's no such wording in the standard. In particular, the
word "privilege" is never used by the standard.'

[toc] | [prev] | [next] | [standalone]

#83569

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> On Sunday, April 10, 2022 at 3:19:27 AM UTC-4, Christian Hanné wrote:
>> Am 10.04.2022 um 07:34 schrieb Keith Thompson: 
> ...
>> > The particular nonsense of his that landed him in my killfile a year and 
>> > a half ago was: 
>> > 
>> > Convertion to uintptr_t involves a privilege-check to the page 
>> > addressed. That's not true for conversions to ptrdiff_t or size_t.
>> That's the exact wording from the standard.
>
> Citation, please? There's no such wording in the standard. In particular, the
> word "privilege" is never used by the standard.'

I suggest not wasting too much time refuting Christian Hanné's
deliberate lies.  He knows perfectly well that there's no such wording
in the standard.  Apparently he enjoys the attention.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#83558

Am 10.04.2022 um 06:39 schrieb james...@alumni.caltech.edu:
> On Sunday, April 10, 2022 at 12:06:23 AM UTC-4, Christian Hanné wrote:
>> Am 02.04.2022 um 05:34 schrieb Andrey Tarasevich:
>>>    #include <iostream>
>>>
>>>    int foo(int a, int b)
>>>    {
>>>      return a + b;
>>>    }
>>>
>>>    int main()
>>>    {
>>>      int i = 1;
>>>      int r = foo(++i, ++i);
>>>      std::cout << r << std::endl;
>>>    }
>>>
>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? ...
>>
>> The ++i's are taken ordered from left to right since the
>> first C version.
> 
> Citation, please?

I wasn't exact: the order is only strict if there are side-effects
like with "++i, ++i".

[toc] | [prev] | [next] | [standalone]

#83568

On Sunday, April 10, 2022 at 3:20:58 AM UTC-4, Christian Hanné wrote:
> Am 10.04.2022 um 06:39 schrieb james...@alumni.caltech.edu: 
> > On Sunday, April 10, 2022 at 12:06:23 AM UTC-4, Christian Hanné wrote: 
> >> Am 02.04.2022 um 05:34 schrieb Andrey Tarasevich: 
> >>> #include <iostream> 
> >>> 
> >>> int foo(int a, int b) 
> >>> { 
> >>> return a + b; 
> >>> } 
> >>> 
> >>> int main() 
> >>> { 
> >>> int i = 1; 
> >>> int r = foo(++i, ++i); 
> >>> std::cout << r << std::endl; 
> >>> } 
> >>> 
> >>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? ... 
> >> 
> >> The ++i's are taken ordered from left to right since the 
> >> first C version. 
> > 
> > Citation, please?
> I wasn't exact: the order is only strict if there are side-effects 
> like with "++i, ++i".

I've already cited the C90 text that said that the order of evaluation is
unspecified; it mentions no such exceptions. The relevant text from the
current standard says that the evaluations are unsequenced, which has
essentially the same meaning, except for it's implications for multi-
threaded code, which C90 didn't discuss.

The as-if rule already applies to the reordering of argument expressions
that don't have side-effects. The entire purpose of saying that the order
of evaluation is unspecified was to give permission for implementation
to reorder the evaluations even if they did have detectable consequences.
That means that if it's important to you which order they get evaluated in,
write code that evaluates them explicitly in the required order before
passing the results to the function call.

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.lang.c++

csiph-web