On 6/18/2024 8:53 PM, Andrey Tarasevich wrote:
On 05/23/24 7:14 AM, Bonita Montero wrote:
Is "x *= ++f * ++f" a valid statement ?
Or is there implementation defined behaviour ?
The question is meaningless without knowing the types of objects
involved. It has no specific answer
If it works correctly for int then it is
syntactically correct:
int x = 1;
int f = 1;
x = 1 * (2 * 3);
++f could be defined as exit(0) for some UDT.
On 6/21/2024 5:10 PM, Richard Damon wrote:
On 6/21/24 5:55 PM, olcott wrote:
On 6/18/2024 8:53 PM, Andrey Tarasevich wrote:
On 05/23/24 7:14 AM, Bonita Montero wrote:
Is "x *= ++f * ++f" a valid statement ?
Or is there implementation defined behaviour ?
The question is meaningless without knowing the types of objects
involved. It has no specific answer
If it works correctly for int then it is
syntactically correct:
int x = 1;
int f = 1;
x = 1 * (2 * 3);
++f could be defined as exit(0) for some UDT.
But, the DEFINITON of ++ doesn't requring that one of the f's are
incremented first, then you use the value, then the othero one.
(unless the rules were actually changed).
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.
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.
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
On 6/22/2024 6:09 AM, David Brown wrote:
On 22/06/2024 06:02, olcott wrote:It would be bad for the standards to be counter-intuitive.
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.
On 6/22/2024 1:18 AM, Keith Thompson wrote:
olcott <[email protected]> writes:
[...]
That is weird I wold have chosen left to right sequence.
I thought that the order of arithmetic operations specifies
left to right sequence.
You may well have thought that. You were wrong. Do you understand that >> now?
"x *= ++f * ++f"
int x = 5;
int y = 3;
For the calculation is question is seems to make no difference to the
result.
x = 5 * (4 * 5)
x = 5 * (5 * 4)
On 6/22/2024 8:45 AM, Richard Damon wrote:
On 6/22/24 8:38 AM, olcott wrote:
On 6/22/2024 1:18 AM, Keith Thompson wrote:
olcott <[email protected]> writes:
[...]
That is weird I wold have chosen left to right sequence.
I thought that the order of arithmetic operations specifies
left to right sequence.
You may well have thought that. You were wrong. Do you understand
that
now?
"x *= ++f * ++f"
int x = 5;
int y = 3;
For the calculation is question is seems to make no difference to the
result.
x = 5 * (4 * 5)
x = 5 * (5 * 4)
In this case no, but if the operation was - it would,
And, as pointed out there is no requirement on the ordering of even
the sub-parts except determinism (we can't use a value we haven't
computed yet). This means the ++ can be interleaved.
And, because of the EXPLICIT requirement on updates to a value needing
to be ordered to avoid undefined behavior,
In other words you fail to comprehend that: (5 * 4) == (4 * 5)
the compiler, seeing that Undefined Behavior exist there can do
ANYTHING it wants with that code.
On 6/22/2024 6:09 AM, David Brown wrote:
On 22/06/2024 06:02, olcott wrote:It would be bad for the standards to be counter-intuitive.
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.
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:It would be bad for the standards to be counter-intuitive.
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.
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.
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
On 6/22/24 8:38 AM, olcott wrote:
On 6/22/2024 1:18 AM, Keith Thompson wrote:
olcott <[email protected]> writes:
[...]
That is weird I wold have chosen left to right sequence.
I thought that the order of arithmetic operations specifies
left to right sequence.
You may well have thought that.� You were wrong.� Do you understand that >>> now?
"x *= ++f * ++f"
int x = 5;
int y = 3;
For the calculation is question is seems to make no difference to the result.
x = 5 * (4 * 5)
x = 5 * (5 * 4)
In this case no, but if the operation was - it would,
And, as pointed out there is no requirement on the ordering of even the sub-parts except determinism (we can't use a value we haven't computed
yet). This means the ++ can be interleaved.
And, because of the EXPLICIT requirement on updates to a value needing
to be ordered to avoid undefined behavior, the compiler, seeing that Undefined Behavior exist there can do ANYTHING it wants with that code.
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:It would be bad for the standards to be counter-intuitive.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 151:53:58 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,621 |