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

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

is "x *= ++f * ++f" a valid statement ?

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

Contents

  is "x *= ++f * ++f" a valid statement ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-23 16:14 +0200
    Re: is "x *= ++f * ++f" a valid statement ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-06-18 18:53 -0700
      Re: is "x *= ++f * ++f" a valid statement ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-19 17:40 +0200
      Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 16:55 -0500
        Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-21 18:10 -0400
          Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 18:06 -0500
            Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-21 20:14 -0400
            Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 17:35 -0700
              Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 22:58 -0500
                Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 23:18 -0700
                  Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 07:38 -0500
                    Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 09:45 -0400
                      Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 09:13 -0500
                        Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 10:23 -0400
                      Re: is "x *= ++f * ++f" a valid statement ? PLO Mikko <mikko.levanto@iki.fi> - 2024-06-23 11:48 +0300
                    Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 17:54 -0700
            Re: is "x *= ++f * ++f" a valid statement ? PLO James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-21 23:42 -0400
              Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 23:02 -0500
                Re: is "x *= ++f * ++f" a valid statement ? PLO David Brown <david.brown@hesbynett.no> - 2024-06-22 13:09 +0200
                  Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 07:40 -0500
                    Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 09:56 -0400
                      Re: is "x *= ++f * ++f" a valid statement ? PLO "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-22 12:14 -0700
                    Re: is "x *= ++f * ++f" a valid statement ? PLO David Brown <david.brown@hesbynett.no> - 2024-06-22 16:52 +0200
                      Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 11:27 -0500
                        Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 13:20 -0400
                        Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 17:55 -0700
                        Re: is "x *= ++f * ++f" a valid statement ? PLO David Brown <david.brown@hesbynett.no> - 2024-06-23 14:46 +0200
                Re: is "x *= ++f * ++f" a valid statement ? PLO James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-22 15:48 -0400
    Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-18 22:27 -0400
    Re: is "x *= ++f * ++f" a valid statement ? olcott <polcott333@gmail.com> - 2024-06-22 21:51 -0500
      Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 21:51 -0700
      Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-23 07:32 -0400
        Re: is "x *= ++f * ++f" a valid statement ? olcott <polcott333@gmail.com> - 2024-06-23 07:59 -0500
          Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-23 14:25 -0400
            Re: is "x *= ++f * ++f" a valid statement ? olcott <polcott333@gmail.com> - 2024-06-23 14:18 -0500
              Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-23 16:23 -0400
                Re: is "x *= ++f * ++f" a valid statement ? David Brown <david.brown@hesbynett.no> - 2024-06-24 09:11 +0200
    Re: is "x *= ++f * ++f" a valid statement ? what@tf.com (testuseri2p) - 2024-07-22 17:51 +0000
      Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-22 14:58 -0700
      Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-22 21:57 -0400
        Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-22 20:40 -0700
          Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-23 10:15 -0400
          Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-23 07:28 -0700
            Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-23 14:42 -0700
              Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-23 15:05 -0700
                Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 06:22 -0700
                  Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-11 14:09 -0700
              Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 06:11 -0700
                Re: is "x *= ++f * ++f" a valid statement ? Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-08-11 09:25 -0400
                Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-11 14:17 -0400
        Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-23 07:32 -0700
      Re: is "x *= ++f * ++f" a valid statement ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-22 19:53 -0700
      Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-23 10:01 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#119495 — Re: is "x *= ++f * ++f" a valid statement ? PLO

On 6/22/24 8:40 AM, olcott wrote:
> On 6/22/2024 6:09 AM, David Brown wrote:
>> On 22/06/2024 06:02, olcott wrote:
>>> On 6/21/2024 10:42 PM, James Kuyper wrote:
>>>> On 6/21/24 7:06 PM, olcott wrote:
>>>> ...
>>>>> When we assume the *= assigns
>>>>> the result of the RHS * the LHS to the LHS
>>>>> "x *= ++f * ++f"
>>>>>
>>>>> means x = x * (++f * ++f)
>>>>> thus cannot have implementation defined behavior.
>>>>
>>>> You are correct about that conclusion, though I don't see what your
>>>> premise has to do with it. The expression ++f * ++f has, all by itself,
>>>> undefined behavior, 
>>>
>>> It would seem to be naturally defined to be Left to right
>>> ++f from 2 to 3
>>> ++f from 3 to 4
>>> 3 * 4
>>>
>>
>> Some programming languages define the order of evaluation for 
>> subexpressions like this.  Neither C nor C++ do (except for specific 
>> operators, which do not include multiplication).
>>
>> It doesn't really matter what you consider "natural" or not - it 
>> matters what the standards say.
>>
>>
> It would be bad for the standards to be counter-intuitive.
> 

No, the Standards are to define the "contract" between the programmer 
and the implementations.

C (and to a lesser extent C++) were envisioned as "High Performance" 
languages designed to get efficiencies of code close to what could be 
created with pure assembly language. Leaving things unspecified that 
still allow the program to be ABLE to express what he wants, and also 
allowing the compiler to generate the most efficient code possible was 
the goal.

Forcing a left-to-right (or right-to-left) order for expressions adds 
possible cost to the code generation due to possible need for spilling 
registers to temporary locations to compute other results.

If you NEED the specific ordering, you can always pre-compute the 
sub-expressions to explicit temporaries, so forcing the order isn't that 
useful\.

One of the main design ideas was that the program is assumed to be 
competent and knows the language well. (This may be less true for C++) 
and gives the programmer powerful tools that do allow them to shoot 
themselves in the foot.

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

#119507 — Re: is "x *= ++f * ++f" a valid statement ? PLO

On 6/22/2024 6:56 AM, Richard Damon wrote:
> On 6/22/24 8:40 AM, olcott wrote:
>> On 6/22/2024 6:09 AM, David Brown wrote:
>>> On 22/06/2024 06:02, olcott wrote:
>>>> On 6/21/2024 10:42 PM, James Kuyper wrote:
>>>>> On 6/21/24 7:06 PM, olcott wrote:
>>>>> ...
>>>>>> When we assume the *= assigns
>>>>>> the result of the RHS * the LHS to the LHS
>>>>>> "x *= ++f * ++f"
>>>>>>
>>>>>> means x = x * (++f * ++f)
>>>>>> thus cannot have implementation defined behavior.
>>>>>
>>>>> You are correct about that conclusion, though I don't see what your
>>>>> premise has to do with it. The expression ++f * ++f has, all by 
>>>>> itself,
>>>>> undefined behavior, 
>>>>
>>>> It would seem to be naturally defined to be Left to right
>>>> ++f from 2 to 3
>>>> ++f from 3 to 4
>>>> 3 * 4
>>>>
>>>
>>> Some programming languages define the order of evaluation for 
>>> subexpressions like this.  Neither C nor C++ do (except for specific 
>>> operators, which do not include multiplication).
>>>
>>> It doesn't really matter what you consider "natural" or not - it 
>>> matters what the standards say.
>>>
>>>
>> It would be bad for the standards to be counter-intuitive.
>>
> 
> No, the Standards are to define the "contract" between the programmer 
> and the implementations.
> 
> C (and to a lesser extent C++) were envisioned as "High Performance" 
> languages designed to get efficiencies of code close to what could be 
> created with pure assembly language. 
[...]

I guess it depends on how one uses C++. It can be just as fast as C, 
with a little "less" work... Fair enough?

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

#119499 — Re: is "x *= ++f * ++f" a valid statement ? PLO

On 22/06/2024 14:40, olcott wrote:
> On 6/22/2024 6:09 AM, David Brown wrote:
>> On 22/06/2024 06:02, olcott wrote:
>>> On 6/21/2024 10:42 PM, James Kuyper wrote:
>>>> On 6/21/24 7:06 PM, olcott wrote:
>>>> ...
>>>>> When we assume the *= assigns
>>>>> the result of the RHS * the LHS to the LHS
>>>>> "x *= ++f * ++f"
>>>>>
>>>>> means x = x * (++f * ++f)
>>>>> thus cannot have implementation defined behavior.
>>>>
>>>> You are correct about that conclusion, though I don't see what your
>>>> premise has to do with it. The expression ++f * ++f has, all by itself,
>>>> undefined behavior, 
>>>
>>> It would seem to be naturally defined to be Left to right
>>> ++f from 2 to 3
>>> ++f from 3 to 4
>>> 3 * 4
>>>
>>
>> Some programming languages define the order of evaluation for 
>> subexpressions like this.  Neither C nor C++ do (except for specific 
>> operators, which do not include multiplication).
>>
>> It doesn't really matter what you consider "natural" or not - it 
>> matters what the standards say.
>>
>>
> It would be bad for the standards to be counter-intuitive.
> 

People's "intuition" varies wildly.  Pretty much any definition would be 
counter-intuitive to someone.  That's why language standards try to have 
precise definitions, rather than just saying "it all works pretty much 
like you'd expect".

We realise the definition of C and C++ expression evaluation does not 
match what you thought was "intuitive".  That does not matter - it would 
not matter even if lots of C and C++ programmers agreed with you.  What 
matters for these languages is what their standards /say/.  That way, we 
can look at clear facts written in official documents, rather than 
trying to rely on what random people think about to be how they imagine 
things ought to be.

You can happily feel that C would be better if evaluation order were 
strictly define.  Some people will agree with that, others will disagree 
- but it will not make a blind bit of difference to the actual /facts/ 
of the matter.

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

#119500 — Re: is "x *= ++f * ++f" a valid statement ? PLO

On 6/22/2024 9:52 AM, David Brown wrote:
> On 22/06/2024 14:40, olcott wrote:
>> On 6/22/2024 6:09 AM, David Brown wrote:
>>> On 22/06/2024 06:02, olcott wrote:
>>>> On 6/21/2024 10:42 PM, James Kuyper wrote:
>>>>> On 6/21/24 7:06 PM, olcott wrote:
>>>>> ...
>>>>>> When we assume the *= assigns
>>>>>> the result of the RHS * the LHS to the LHS
>>>>>> "x *= ++f * ++f"
>>>>>>
>>>>>> means x = x * (++f * ++f)
>>>>>> thus cannot have implementation defined behavior.
>>>>>
>>>>> You are correct about that conclusion, though I don't see what your
>>>>> premise has to do with it. The expression ++f * ++f has, all by 
>>>>> itself,
>>>>> undefined behavior, 
>>>>
>>>> It would seem to be naturally defined to be Left to right
>>>> ++f from 2 to 3
>>>> ++f from 3 to 4
>>>> 3 * 4
>>>>
>>>
>>> Some programming languages define the order of evaluation for 
>>> subexpressions like this.  Neither C nor C++ do (except for specific 
>>> operators, which do not include multiplication).
>>>
>>> It doesn't really matter what you consider "natural" or not - it 
>>> matters what the standards say.
>>>
>>>
>> It would be bad for the standards to be counter-intuitive.
>>
> 
> People's "intuition" varies wildly.  Pretty much any definition would be 
> counter-intuitive to someone.  That's why language standards try to have 
> precise definitions, rather than just saying "it all works pretty much 
> like you'd expect".
> 
> We realise the definition of C and C++ expression evaluation does not 
> match what you thought was "intuitive".  That does not matter - it would 
> not matter even if lots of C and C++ programmers agreed with you.  What 
> matters for these languages is what their standards /say/.  That way, we 
> can look at clear facts written in official documents, rather than 
> trying to rely on what random people think about to be how they imagine 
> things ought to be.
> 
> You can happily feel that C would be better if evaluation order were 
> strictly define.  Some people will agree with that, others will disagree 
> - but it will not make a blind bit of difference to the actual /facts/ 
> of the matter.
> 
> 

Then make the rule strict left to right unless otherwise specified.
int x = 2 + 3 * 5; // is otherwise specified by operator precedence.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#119503 — Re: is "x *= ++f * ++f" a valid statement ? PLO

On 6/22/24 12:27 PM, olcott wrote:
> On 6/22/2024 9:52 AM, David Brown wrote:
>> On 22/06/2024 14:40, olcott wrote:
>>> On 6/22/2024 6:09 AM, David Brown wrote:
>>>> On 22/06/2024 06:02, olcott wrote:
>>>>> On 6/21/2024 10:42 PM, James Kuyper wrote:
>>>>>> On 6/21/24 7:06 PM, olcott wrote:
>>>>>> ...
>>>>>>> When we assume the *= assigns
>>>>>>> the result of the RHS * the LHS to the LHS
>>>>>>> "x *= ++f * ++f"
>>>>>>>
>>>>>>> means x = x * (++f * ++f)
>>>>>>> thus cannot have implementation defined behavior.
>>>>>>
>>>>>> You are correct about that conclusion, though I don't see what your
>>>>>> premise has to do with it. The expression ++f * ++f has, all by 
>>>>>> itself,
>>>>>> undefined behavior, 
>>>>>
>>>>> It would seem to be naturally defined to be Left to right
>>>>> ++f from 2 to 3
>>>>> ++f from 3 to 4
>>>>> 3 * 4
>>>>>
>>>>
>>>> Some programming languages define the order of evaluation for 
>>>> subexpressions like this.  Neither C nor C++ do (except for specific 
>>>> operators, which do not include multiplication).
>>>>
>>>> It doesn't really matter what you consider "natural" or not - it 
>>>> matters what the standards say.
>>>>
>>>>
>>> It would be bad for the standards to be counter-intuitive.
>>>
>>
>> People's "intuition" varies wildly.  Pretty much any definition would 
>> be counter-intuitive to someone.  That's why language standards try to 
>> have precise definitions, rather than just saying "it all works pretty 
>> much like you'd expect".
>>
>> We realise the definition of C and C++ expression evaluation does not 
>> match what you thought was "intuitive".  That does not matter - it 
>> would not matter even if lots of C and C++ programmers agreed with 
>> you.  What matters for these languages is what their standards /say/.  
>> That way, we can look at clear facts written in official documents, 
>> rather than trying to rely on what random people think about to be how 
>> they imagine things ought to be.
>>
>> You can happily feel that C would be better if evaluation order were 
>> strictly define.  Some people will agree with that, others will 
>> disagree - but it will not make a blind bit of difference to the 
>> actual /facts/ of the matter.
>>
>>
> 
> Then make the rule strict left to right unless otherwise specified.
> int x = 2 + 3 * 5; // is otherwise specified by operator precedence.
> 

Join the ISO Committe and try to lobby for it.

There are good reasons it isn't defined that way.

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

#119515 — Re: is "x *= ++f * ++f" a valid statement ? PLO

olcott <polcott333@gmail.com> writes:
[...]
> Then make the rule strict left to right unless otherwise specified.
> int x = 2 + 3 * 5; // is otherwise specified by operator precedence.

No.

Are we done here?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#119527 — Re: is "x *= ++f * ++f" a valid statement ? PLO

On 22/06/2024 18:27, olcott wrote:
> On 6/22/2024 9:52 AM, David Brown wrote:
>> On 22/06/2024 14:40, olcott wrote:
>>> On 6/22/2024 6:09 AM, David Brown wrote:
>>>> On 22/06/2024 06:02, olcott wrote:
>>>>> On 6/21/2024 10:42 PM, James Kuyper wrote:
>>>>>> On 6/21/24 7:06 PM, olcott wrote:
>>>>>> ...
>>>>>>> When we assume the *= assigns
>>>>>>> the result of the RHS * the LHS to the LHS
>>>>>>> "x *= ++f * ++f"
>>>>>>>
>>>>>>> means x = x * (++f * ++f)
>>>>>>> thus cannot have implementation defined behavior.
>>>>>>
>>>>>> You are correct about that conclusion, though I don't see what your
>>>>>> premise has to do with it. The expression ++f * ++f has, all by 
>>>>>> itself,
>>>>>> undefined behavior, 
>>>>>
>>>>> It would seem to be naturally defined to be Left to right
>>>>> ++f from 2 to 3
>>>>> ++f from 3 to 4
>>>>> 3 * 4
>>>>>
>>>>
>>>> Some programming languages define the order of evaluation for 
>>>> subexpressions like this.  Neither C nor C++ do (except for specific 
>>>> operators, which do not include multiplication).
>>>>
>>>> It doesn't really matter what you consider "natural" or not - it 
>>>> matters what the standards say.
>>>>
>>>>
>>> It would be bad for the standards to be counter-intuitive.
>>>
>>
>> People's "intuition" varies wildly.  Pretty much any definition would 
>> be counter-intuitive to someone.  That's why language standards try to 
>> have precise definitions, rather than just saying "it all works pretty 
>> much like you'd expect".
>>
>> We realise the definition of C and C++ expression evaluation does not 
>> match what you thought was "intuitive".  That does not matter - it 
>> would not matter even if lots of C and C++ programmers agreed with 
>> you.  What matters for these languages is what their standards /say/.  
>> That way, we can look at clear facts written in official documents, 
>> rather than trying to rely on what random people think about to be how 
>> they imagine things ought to be.
>>
>> You can happily feel that C would be better if evaluation order were 
>> strictly define.  Some people will agree with that, others will 
>> disagree - but it will not make a blind bit of difference to the 
>> actual /facts/ of the matter.
>>
>>
> 
> Then make the rule strict left to right unless otherwise specified.
> int x = 2 + 3 * 5; // is otherwise specified by operator precedence.
> 


What do you mean, "Make the rule" ?  /I/ didn't write the C++ or C 
standards - I can't make any rules there.  Nor can anyone else here. 
And even if I could, I would not change this.  C and C++ made these 
design decisions for good reasons, and I agree with the decision.

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

#119509 — Re: is "x *= ++f * ++f" a valid statement ? PLO

On 22/06/2024 06:02, olcott wrote:
> On 6/21/2024 10:42 PM, James Kuyper wrote:
>> On 6/21/24 7:06 PM, olcott wrote:
>> ...
>>> When we assume the *= assigns
>>> the result of the RHS * the LHS to the LHS
>>> "x *= ++f * ++f"
>>>
>>> means x = x * (++f * ++f)
>>> thus cannot have implementation defined behavior.
>>
>> You are correct about that conclusion, though I don't see what your
>> premise has to do with it. The expression ++f * ++f has, all by itself,
>> undefined behavior, 
> 
> It would seem to be naturally defined to be Left to right
> ++f from 2 to 3
> ++f from 3 to 4
> 3 * 4

C is deliberately underspecified, to allow implementations more freedom
to optimize their code. The key point is that ++f * ++f modifies the
same object twice without any requirement that the updates occur in a
particular order. This means an implementation is allowed to generate
code that implements those modifications in such a way that they could
interfere with each other.

Consider, for example, an implementation where f is a 64-bit long long
on a system with no hardware support for types longer than 16 bits, so
that it needs to generate multiple machine instructions to implement
++f. If you were calculating ++f * ++g, it would be entirely feasible to
interleave the instructions that calculate ++f and ++g; there might, in
fact, be some advantage to doing so. When the implementor writes the
code that implements that interleaving, the fact that ++f * ++f would
have undefined behavior relieves the implementor of any responsibility
for checking whether the two ++ operations apply to the same object,
which simplifies the logic of that code.

I'm not saying that these rules were chosen with this particular example
in mind, but only that examples like this one were the reason why C
takes the general approach that it does: unless otherwise specified,
operations on sub-expressions are unordered with respect to each other,
and when an action modifying an object is unordered with respect to
another operation that either reads or modifies that object, the
behavior is undefined.

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

#119476

On 5/23/24 10:14 AM, Bonita Montero wrote:
> Is "x *= ++f * ++f" a valid statement ?
> Or is there implementation defined behaviour ?

For a built in type, the behavior of the two ++ operations on f are 
unordered, and that will lead to undefined behavior.

If f is of a user defined type, with an operator++ defined, I think 
while the order the two operations is unspecified, they can't get 
intermixed, so I think it may just be unspecified behavior, and no nasal 
demons allowed.

There is no requirement for the implementation to define the behavior, 
and it doesn't need to be consistant.


"Valid" would be a question of semantics. There is nothing that requires 
a diagnostic, and the implementation has no grounds for not creating a 
program. but for built in types, there is no requirements on what 
happens, and for user types the order things happen is unspecified.

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

#119517

On 5/23/2024 9:14 AM, Bonita Montero wrote:
> Is "x *= ++f * ++f" a valid statement ?
> Or is there implementation defined behaviour ?

For that specific case the result would seem to be identical
no matter the sequence of the incrementations for int type: f.
I might not understand this fully.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#119518

olcott <polcott333@gmail.com> writes:
> On 5/23/2024 9:14 AM, Bonita Montero wrote:
>> Is "x *= ++f * ++f" a valid statement ?
>> Or is there implementation defined behaviour ?
>
> For that specific case the result would seem to be identical
> no matter the sequence of the incrementations for int type: f.
> I might not understand this fully.

It's been explained to you in great detail, and for whatever reason you
choose not to understand it.  For the sake of others who might believe
you, I urge you to stop.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#119521

On 6/22/24 10:51 PM, olcott wrote:
> On 5/23/2024 9:14 AM, Bonita Montero wrote:
>> Is "x *= ++f * ++f" a valid statement ?
>> Or is there implementation defined behaviour ?
> 
> For that specific case the result would seem to be identical
> no matter the sequence of the incrementations for int type: f.
> I might not understand this fully.
> 

Nope, the issue is that increment isn't an atomic operation, but the 
storing of the incremented result is allowed to happen at any point 
prior to the end expression it is part of. (In older terms, the sequence 
point);

If f was a user defined type, with a user define operator++ then yes, it 
is bracketed with sequencing and the two will not overlap, but not for 
primative types.

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

#119528

On 6/23/2024 6:32 AM, Richard Damon wrote:
> On 6/22/24 10:51 PM, olcott wrote:
>> On 5/23/2024 9:14 AM, Bonita Montero wrote:
>>> Is "x *= ++f * ++f" a valid statement ?
>>> Or is there implementation defined behaviour ?
>>
>> For that specific case the result would seem to be identical
>> no matter the sequence of the incrementations for int type: f.
>> I might not understand this fully.
>>
> 
> Nope, the issue is that increment isn't an atomic operation, but the 
> storing of the incremented result is allowed to happen at any point 
> prior to the end expression it is part of. (In older terms, the sequence 
> point);
> 
> If f was a user defined type, with a user define operator++ then yes, it 
> is bracketed with sequencing and the two will not overlap, but not for 
> primative types.

It is not f++, it is ++f meaning the the operation must occur before
the value is accessed.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#119529

On 6/23/24 8:59 AM, olcott wrote:
> On 6/23/2024 6:32 AM, Richard Damon wrote:
>> On 6/22/24 10:51 PM, olcott wrote:
>>> On 5/23/2024 9:14 AM, Bonita Montero wrote:
>>>> Is "x *= ++f * ++f" a valid statement ?
>>>> Or is there implementation defined behaviour ?
>>>
>>> For that specific case the result would seem to be identical
>>> no matter the sequence of the incrementations for int type: f.
>>> I might not understand this fully.
>>>
>>
>> Nope, the issue is that increment isn't an atomic operation, but the 
>> storing of the incremented result is allowed to happen at any point 
>> prior to the end expression it is part of. (In older terms, the 
>> sequence point);
>>
>> If f was a user defined type, with a user define operator++ then yes, 
>> it is bracketed with sequencing and the two will not overlap, but not 
>> for primative types.
> 
> It is not f++, it is ++f meaning the the operation must occur before
> the value is accessed.
> 

But the writing back of the result does not.

The ++ and -- operators are NOT defined to be in any way "atomic".

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

#119530

On 6/23/2024 1:25 PM, Richard Damon wrote:
> On 6/23/24 8:59 AM, olcott wrote:
>> On 6/23/2024 6:32 AM, Richard Damon wrote:
>>> On 6/22/24 10:51 PM, olcott wrote:
>>>> On 5/23/2024 9:14 AM, Bonita Montero wrote:
>>>>> Is "x *= ++f * ++f" a valid statement ?
>>>>> Or is there implementation defined behaviour ?
>>>>
>>>> For that specific case the result would seem to be identical
>>>> no matter the sequence of the incrementations for int type: f.
>>>> I might not understand this fully.
>>>>
>>>
>>> Nope, the issue is that increment isn't an atomic operation, but the 
>>> storing of the incremented result is allowed to happen at any point 
>>> prior to the end expression it is part of. (In older terms, the 
>>> sequence point);
>>>
>>> If f was a user defined type, with a user define operator++ then yes, 
>>> it is bracketed with sequencing and the two will not overlap, but not 
>>> for primative types.
>>
>> It is not f++, it is ++f meaning the the operation must occur before
>> the value is accessed.
>>
> 
> But the writing back of the result does not.
> 
> The ++ and -- operators are NOT defined to be in any way "atomic".

In other words it is not a direct memory increment?

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#119531

On 6/23/24 3:18 PM, olcott wrote:
> On 6/23/2024 1:25 PM, Richard Damon wrote:
>> On 6/23/24 8:59 AM, olcott wrote:
>>> On 6/23/2024 6:32 AM, Richard Damon wrote:
>>>> On 6/22/24 10:51 PM, olcott wrote:
>>>>> On 5/23/2024 9:14 AM, Bonita Montero wrote:
>>>>>> Is "x *= ++f * ++f" a valid statement ?
>>>>>> Or is there implementation defined behaviour ?
>>>>>
>>>>> For that specific case the result would seem to be identical
>>>>> no matter the sequence of the incrementations for int type: f.
>>>>> I might not understand this fully.
>>>>>
>>>>
>>>> Nope, the issue is that increment isn't an atomic operation, but the 
>>>> storing of the incremented result is allowed to happen at any point 
>>>> prior to the end expression it is part of. (In older terms, the 
>>>> sequence point);
>>>>
>>>> If f was a user defined type, with a user define operator++ then 
>>>> yes, it is bracketed with sequencing and the two will not overlap, 
>>>> but not for primative types.
>>>
>>> It is not f++, it is ++f meaning the the operation must occur before
>>> the value is accessed.
>>>
>>
>> But the writing back of the result does not.
>>
>> The ++ and -- operators are NOT defined to be in any way "atomic".
> 
> In other words it is not a direct memory increment?
> 

Not required to be, since not all computers have one.

It CAN be, (and may well be on many processors) but isn't required to be.

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

#119532

On 23/06/2024 22:23, Richard Damon wrote:
> On 6/23/24 3:18 PM, olcott wrote:
>> On 6/23/2024 1:25 PM, Richard Damon wrote:
>>> On 6/23/24 8:59 AM, olcott wrote:
>>>> On 6/23/2024 6:32 AM, Richard Damon wrote:
>>>>> On 6/22/24 10:51 PM, olcott wrote:
>>>>>> On 5/23/2024 9:14 AM, Bonita Montero wrote:
>>>>>>> Is "x *= ++f * ++f" a valid statement ?
>>>>>>> Or is there implementation defined behaviour ?
>>>>>>
>>>>>> For that specific case the result would seem to be identical
>>>>>> no matter the sequence of the incrementations for int type: f.
>>>>>> I might not understand this fully.
>>>>>>
>>>>>
>>>>> Nope, the issue is that increment isn't an atomic operation, but 
>>>>> the storing of the incremented result is allowed to happen at any 
>>>>> point prior to the end expression it is part of. (In older terms, 
>>>>> the sequence point);
>>>>>
>>>>> If f was a user defined type, with a user define operator++ then 
>>>>> yes, it is bracketed with sequencing and the two will not overlap, 
>>>>> but not for primative types.
>>>>
>>>> It is not f++, it is ++f meaning the the operation must occur before
>>>> the value is accessed.
>>>>
>>>
>>> But the writing back of the result does not.
>>>
>>> The ++ and -- operators are NOT defined to be in any way "atomic".
>>
>> In other words it is not a direct memory increment?
>>
> 
> Not required to be, since not all computers have one.
> 
> It CAN be, (and may well be on many processors) but isn't required to be.

Very few modern architectures support direct memory operations now. 
Even ISA's that have instructions that appear to be direct memory 
operations will often split them into separate read, modify and write 
microops.  And for multi-core systems, atomic memory operations are very 
costly as they involve bus locks and synchronisation - so compilers 
don't generate them unless you specifically ask for them.

And of course operations like ++f or f++ are very rarely atomic if you 
are using the result of the operation, even if the processor supports an 
atomic memory increment - you still need to read the memory, before or 
after the increment.

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

#119712

I'd say in simple words, if you alter a variable multiple times in one
statement, you get UB.

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

#119717

what@tf.com (testuseri2p) writes:
> I'd say in simple words, if you alter a variable multiple times in one
> statement, you get UB.

That's a little too simple.  You can alter a variable multiple times in
one statement as long as the two modifications are *sequenced*, for
example if they're separated by a comma operator.

In the code fragment in the subject line, the two occurrences of "++f"
are unsequenced, so the behavior is undefined.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#119719

On 7/22/24 13:51, testuseri2p wrote:
> I'd say in simple words, if you alter a variable multiple times in one
> statement, you get UB.

The correct (and admittedly more complicated) statement of the relevant
rule is:
"If a side effect on a memory location (6.7.1) is unsequenced relative
to either another side effect on the same memory location or a value
computation using the value of any object in the same memory location,
and they are not potentially concurrent (6.9.2), the behavior is undefined."

The biggest difference between the exact rule and what you said is that
two different updates to a variable may occur in the same statement, so
long as they are sequenced relative to each other. Sub-expressions of an
expression are sequenced before evaluation of the expression itself. In
general, the sub-expressions of a expression are unsequenced, but there
several exceptions: ||, &&, ?:, the comma operator.

A minor detail is that a variable must be declared, whereas memory
locations can, for instance, be part of allocated memory for which no
declaration exists - it is still undefined behavior to write code that
applies unsequence side-effects to such memory locations.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web