the expression in the function position is evaluated before all the arguments and the evaluations of the arguments are indeterminately sequenced, but with no interleaving.
template<typename Ts...>
void func(Ts&&... args)
{
vector<int> v;
v.reserve(sizeof...(Ts));
(v.insert(v.end(), std::forward<Ts>(args)), ...);
}
template<typename Ts...>
void func(Ts&&... args)
{
vector<int> v;
v.reserve(sizeof...(Ts));
auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args))...);
}
For the benefit of those reading up on this for the first time, and who did not have the pleasure of participating in previous discussions on the topic, there are several good reasons for preserving the current unspecified ordering. Among those I find most compelling are refactoring, optimization, backwards compatibility. Also, of course, with the ordering unspecified implementations are at liberty to fix on an LTR or RTL ordering, and there is nothing preventing a further version of the standard from making that change, but to do so now would be nearly irrevocable if it proved dissatisfactory.
Yes, your understanding is correct to the best of my knowledge. It's mildly surprising, certainly; but C++ has plenty of mildly surprising corner cases. In mitigation, the syntax is different (no comma) so you can hardly say that it's the same code wrapped in a function call, and the code as written is somewhat artificial (why not use array directly with a braced-init-list via template argument deduction)?
For the benefit of those reading up on this for the first time, and who did not have the pleasure of participating in previous discussions on the topic, there are several good reasons for preserving the current unspecified ordering. Among those I find most compelling are refactoring, optimization, backwards compatibility. Also, of course, with the ordering unspecified implementations are at liberty to fix on an LTR or RTL ordering, and there is nothing preventing a further version of the standard from making that change, but to do so now would be nearly irrevocable if it proved dissatisfactory.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9f9be10e-ea35-4fc8-84c5-e71c770063dd%40isocpp.org.
The irrevocable wrong decision that was made was that in assignments, the RHS is evaluated before the LHS.
Yes, your understanding is correct to the best of my knowledge. It's mildly surprising, certainly; but C++ has plenty of mildly surprising corner cases.
In mitigation, the syntax is different (no comma) so you can hardly say that it's the same code wrapped in a function call,
and the code as written is somewhat artificial (why not use array directly with a braced-init-list via template argument deduction)?
auto inserts = array<vector<int>::iterator, sizeof...(args)>{v.insert(v.end(), std::forward<Ts>(args))...}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org.
The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.
The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
The C++17 change is wrong in two parts.
First, it does not specify order of evaluation completely, so accidentally working code will continue to be a problem. This can be fixed in a later version of the standard.
Second, it specifies that in assignments, the RHS is evaluated before the LHS (I believe because of a mistaken notion of what associativity means). This makes the Standard irretrievably broken, because it becomes impossible to specify the correct left-to-right behavior in the future.
The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.
The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
The C++17 change is wrong in two parts.
First, it does not specify order of evaluation completely, so accidentally working code will continue to be a problem. This can be fixed in a later version of the standard.
Second, it specifies that in assignments, the RHS is evaluated before the LHS (I believe because of a mistaken notion of what associativity means). This makes the Standard irretrievably broken, because it becomes impossible to specify the correct left-to-right behavior in the future.
What I was thing of was
To me it made sense to order it like this:auto temp_b = b();auto temp_c = c();auto temp_sum = temp_b + temp_c;a() = temp_sum;This is, I believe, based on how I might write this in english:Compute b() and c(), add them together, and assign that value to a().Are you suggesting this instead?auto &&temp_a = a();auto &&temp_b = b();auto &&temp_c = c();temp_a = temp_b + temp_c;
The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.
The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
The C++17 change is wrong in two parts.
First, it does not specify order of evaluation completely, so accidentally working code will continue to be a problem. This can be fixed in a later version of the standard.
Second, it specifies that in assignments, the RHS is evaluated before the LHS (I believe because of a mistaken notion of what associativity means). This makes the Standard irretrievably broken, because it becomes impossible to specify the correct left-to-right behavior in the future.
--On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <greg...@gmail.com> wrote:On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:--The irrevocable wrong decision that was made was that in assignments, the RHS is evaluated before the LHS.Why do you consider that the wrong decision, and what would have been the right decision?
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org.
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com.
On 11 Jul 2016 9:35 p.m., "Nicol Bolas" <jmck...@gmail.com> wrote:
>
> On Sunday, July 10, 2016 at 5:52:14 PM UTC-4, Edward Catmur wrote:
>>
>> In mitigation, the syntax is different (no comma) so you can hardly say that it's the same code wrapped in a function call,
>
>
> It is as far as the user is concerned. Capturing the return value of expressions should not suddenly cause the code's behavior to change. Even if you had to give it a different spelling to make it work right.
If you don't understand the reason behind the different spelling you're programming by permutation. Which is a fine enough technique but will bite you sooner or later.
>> and the code as written is somewhat artificial (why not use array directly with a braced-init-list via template argument deduction)?
>
>
> ... because that's not possible? Maybe I'm misunderstanding what you're suggesting here. But I don't know of a way to turn a braced-init-list into a std::array that involves template argument deduction.
>
> Sure, you could do this:
>
> auto inserts = array<vector<int>::iterator, sizeof...(args)>{v.insert(v.end(), std::forward<Ts>(args))...}
>
> But the whole point of `make_array` is that you don't have to specify the type or the count of values; they can be deduced. Since `std::array` is an aggregate, I see no way for it to deduce the number of arguments or their types. Even the new constructor deduction scheme introduced in C++17 only applies to actual constructors, and `array` doesn't have any.
>
No, you're right, I was expecting that template deduction guides should work for array. It's a pity if they won't.
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.
That sounds like a performance nightmare.
> The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
There will always be implementation variance especially between platforms. A blanket statement that it is always bad ignores the multitude of reasons to permit and encourage implementation variance. And of course the implementation variance already exists, so you won't be able to change the behavior of existing platforms.
> The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient reader of natural languages reads sentences and paragraphs in a single glance.
And is making C++ more similar to Java supposed to be a *good* thing?
> The C++17 change is wrong in two parts.
>
> First, it does not specify order of evaluation completely, so accidentally working code will continue to be a problem. This can be fixed in a later version of the standard.
>
> Second, it specifies that in assignments, the RHS is evaluated before the LHS (I believe because of a mistaken notion of what associativity means). This makes the Standard irretrievably broken, because it becomes impossible to specify the correct left-to-right behavior in the future.
Quite.
> On Mon, Jul 11, 2016 at 3:16 PM, Greg Marr <greg...@gmail.com> wrote:
>>
>> On Monday, July 11, 2016 at 12:17:31 PM UTC-4, Hyman Rosen wrote:
>>>
>>> The irrevocable wrong decision that was made was that in assignments, the RHS is evaluated before the LHS.
>>
>>
>> Why do you consider that the wrong decision, and what would have been the right decision?
>>
>> --
>> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
>>
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3c4df92-5e44-441b-8f06-e039623bb9a9%40isocpp.org.
>
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/wahN6MBQt68/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdanbWiH%2BFixdzPLjLnD%2BfJTCr25yFphPSz%3DS45ryQQu5A%40mail.gmail.com.
C++17's CD has apparently voted in the expression evaluation order proposal, but as I understand it, they used the "Alternate Evaluation Order for Function Calls" That says:the expression in the function position is evaluated before all the arguments and the evaluations of the arguments are indeterminately sequenced, but with no interleaving.
So, I want to make sure I understand something.
This has well defined behavior:
template<typename Ts...>
void func(Ts&&... args)
{
vector<int> v;
v.reserve(sizeof...(Ts));
(v.insert(v.end(), std::forward<Ts>(args)), ...);
}
This will insert to the end of `v` every element in `args`, in the order of the arguments passed to `func`.
But this will not:
template<typename Ts...>
void func(Ts&&... args)
{
vector<int> v;
v.reserve(sizeof...(Ts));
auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args))...);
}
So, by the mere act of calling a function on the return values, the state of `v` is unspecified.
Now, the new sequencing rules will at least ensure that this code results in a valid `v`. That is, each `v.end` will be called, followed by its corresponding `v.insert`. There won't be any interleaving, so `v` will have actual data in it in some order. And the returned iterators will all be equally valid.
But there also won't be a guaranteed order. All because it was wrapped in a function call.
Is my understanding of things correct? Would people not consider this highly surprising behavior?
The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.
The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
The C++17 change is wrong in two parts.
First, it does not specify order of evaluation completely, so accidentally working code will continue to be a problem. This can be fixed in a later version of the standard.
Second, it specifies that in assignments, the RHS is evaluated before the LHS (I believe because of a mistaken notion of what associativity means). This makes the Standard irretrievably broken, because it becomes impossible to specify the correct left-to-right behavior in the future.
The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.
The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
The C++17 change is wrong in two parts.
First, it does not specify order of evaluation completely, so accidentally working code will continue to be a problem. This can be fixed in a later version of the standard.
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.That sounds like a performance nightmare.
> The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
There will always be implementation variance especially between platforms. A blanket statement that it is always bad ignores the multitude of reasons to permit and encourage implementation variance. And of course the implementation variance already exists, so you won't be able to change the behavior of existing platforms.
> The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient reader of natural languages reads sentences and paragraphs in a single glance.
And is making C++ more similar to Java supposed to be a *good* thing?
在 2016年7月12日星期二 UTC+8上午8:27:41,Edward Catmur写道:
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.That sounds like a performance nightmare.
This can be resolved by introducing some specific primitives to specify the evaluation order not obeying this rule. However, they will be lengthy and users will be reluctant to use them. Users will have excuse granted by the default rule.
The true harm of such decision is, it encourages stupidity and laziness as the default case. Freedom of expressiveness is defeated by freedom of lack of consideration.
This is offensive to people who want to write the "more correct" (more precise, easier to read, easier to maintain) - not merely "runnable" code: it makes they harder to achieve their goals while giving them nothing.
auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args))...);
> The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
There will always be implementation variance especially between platforms. A blanket statement that it is always bad ignores the multitude of reasons to permit and encourage implementation variance. And of course the implementation variance already exists, so you won't be able to change the behavior of existing platforms.
> The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient reader of natural languages reads sentences and paragraphs in a single glance.
Yes. This is exactly my experience, and not only to C++. If a user can only work under a single strict order with some sequenced materials, I doubt his/her brain is damaged. Moreover, assuming left-to-right to be the natural order may be offensive to people who are using natural languages with right-to-left natural layout.
And is making C++ more similar to Java supposed to be a *good* thing?
And I can imagine making C++ less similar to C here has more impact in reality.
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.That sounds like a performance nightmare.
> The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
There will always be implementation variance especially between platforms. A blanket statement that it is always bad ignores the multitude of reasons to permit and encourage implementation variance. And of course the implementation variance already exists, so you won't be able to change the behavior of existing platforms.
> The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient reader of natural languages reads sentences and paragraphs in a single glance.
And is making C++ more similar to Java supposed to be a *good* thing?
On Monday, July 11, 2016 at 10:46:43 PM UTC-4, FrankHB1989 wrote:在 2016年7月12日星期二 UTC+8上午8:27:41,Edward Catmur写道:
On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.That sounds like a performance nightmare.
This can be resolved by introducing some specific primitives to specify the evaluation order not obeying this rule. However, they will be lengthy and users will be reluctant to use them. Users will have excuse granted by the default rule.
The true harm of such decision is, it encourages stupidity and laziness as the default case. Freedom of expressiveness is defeated by freedom of lack of consideration.
Accepting reality should superseded all else. Reality has shown us that, 99% of the time, programmers assume things happen in a left-to-right order. Which means that your vaunted "freedom of expressiveness" is only being used 1% of the time.
C++ is a practical language, not some ivory-tower experiment. We must bow to reality when it is presented to us. And reality tells us, time and again, that we lose far more from undefined evaluation order than we gain from it. We lose time in debugging. We lose time in development. We lose mental time in having to think about it.
The only thing we gain from it is making it harder to become a proficient C++ programmer. And that's not a benefit of the language.
This is offensive to people who want to write the "more correct" (more precise, easier to read, easier to maintain) - not merely "runnable" code: it makes they harder to achieve their goals while giving them nothing.
I don't know; I find this to be quite "correct" code:
auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args))...);
This code is very clear: for each item in the pack, insert it at the end, capturing those iterators in an array. I see no reason to express this code in a more verbose way. Well, besides the fact that it doesn't work, but that's only due to a silly language rule.
What is the "more correct" alternative? Show me how to write that same code in a way that is as clear and concise as this, which doesn't provoke undefined behavior.
And if `make_array` offends you, feel free to change it into any function that would take a sequence of iterators.> The reason for defining order is to avoid code that "accidentally works" - that is, code that has order dependencies such that its behavior is undefined or unspecified, but happens to be built with a compiler whose behavior matches the programmer's intent. Such code can mysteriously break when built on a different platform, long after it was written and has appeared to work correctly. We have personally encountered this situation in our company.
There will always be implementation variance especially between platforms. A blanket statement that it is always bad ignores the multitude of reasons to permit and encourage implementation variance. And of course the implementation variance already exists, so you won't be able to change the behavior of existing platforms.
> The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient reader of natural languages reads sentences and paragraphs in a single glance.
Yes. This is exactly my experience, and not only to C++. If a user can only work under a single strict order with some sequenced materials, I doubt his/her brain is damaged. Moreover, assuming left-to-right to be the natural order may be offensive to people who are using natural languages with right-to-left natural layout.
Wait a minute. Having a left-to-right order is offensive to people who use right-to-left languages... but having all our keywords being English is perfectly fine? What about the fact that the parser goes left-to-right; are they offended by that too? Maybe my brain is too damaged from not being able to read paragraphs at a single glance, but I really can't follow your logic here.
Also, programming isn't a sport; you don't get extra points for degree of difficulty.And is making C++ more similar to Java supposed to be a *good* thing?
And I can imagine making C++ less similar to C here has more impact in reality.
C is not a subset of C++, and it hasn't been since... C++98. While there are people who write in the subset between C and C++, this is usually code intended to be compiled as either. And such people are generally writing C which can be compiled as C++, not writing C++ that can be compiled as C. So they will write it under C's rules first and foremost. Porting the other way is much rarer.
Also, let's not forget that, when it comes to complex expressions, C has nothing on C++. We have so many more tools to write complicated expressions than C does. That's why my example involved parameter packs and fold expressions; to me, they're the poster-child for making sequences of complex expressions that the user will expect to evaluate in order.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/59cb4a9f-f479-4416-ad7a-560f97af60bf%40isocpp.org.
The true harm of such decision is, it encourages stupidity and laziness as the default case.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnM%2Bz6F%3DMfruh6baZX7_5XXkrUGxHkh_%2B_8_c1j60gm_A%40mail.gmail.com.
Accepting reality should superseded all else. Reality has shown us that, 99% of the time, programmers assume things happen in a left-to-right order. Which means that your vaunted "freedom of expressiveness" is only being used 1% of the time.
C++ is a practical language, not some ivory-tower experiment. We must bow to reality when it is presented to us. And reality tells us, time and again, that we lose far more from undefined evaluation order than we gain from it. We lose time in debugging. We lose time in development. We lose mental time in having to think about it.
I don't know; I find this to be quite "correct" code:
auto inserts = make_array(v.insert(v.end(), std::forward<Ts>(args))...);
This code is very clear: for each item in the pack, insert it at the end, capturing those iterators in an array. I see no reason to express this code in a more verbose way. Well, besides the fact that it doesn't work, but that's only due to a silly language rule.
What is the "more correct" alternative? Show me how to write that same code in a way that is as clear and concise as this, which doesn't provoke undefined behavior.
And if `make_array` offends you, feel free to change it into any function that would take a sequence of iterators.
Also, let's not forget that, when it comes to complex expressions, C has nothing on C++. We have so many more tools to write complicated expressions than C does. That's why my example involved parameter packs and fold expressions; to me, they're the poster-child for making sequences of complex expressions that the user will expect to evaluate in order.
If you're writing already complicated expressions, why complicate them further by making them order-dependent?
On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.That sounds like a performance nightmare.
I've heard a lot of "sounds like" out of people defending the undefined order rules. I've heard far less "certainly is". Is there any genuine evidence of this "performance nightmare", or is it just fear of the unknown?
How many compilers actually use the undefined evaluation order rules to optimize code? Do they re-order expressions based on what is best for that specific expression? Or do they always evaluate expressions in an arbitrary order? Because if such flexibility is not actually making code faster, then the variance is pointless and should be done away with.
> The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient reader of natural languages reads sentences and paragraphs in a single glance.
Let's pretend this was true (despite the undeniable fact that "experienced users" make these mistakes too).
So what? Are we supposed to restrict C++ to "experienced users" as you define it?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdavQjZYLNHK8u4BPTq4JVKHfP5zDqGdymdMYg9hHeVHpg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZYhVTMLPQsPUw6RkN_hK%3DniYeFrPe_4H2y70bpW%3DSSng%40mail.gmail.com.
Please look at the technical arguments instead of calling people who disagree with you "irrational".
On Tue, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:Please look at the technical arguments instead of calling people who disagree with you "irrational".It's not a matter of technical arguments, it's a matter of values (as you say). Science can tell you how to accomplish what you want, but it can't tell you what to want. For me, the values involved in having a programming language that is simply specified and deterministic and consistent far outweigh the possible optimization benefit in letting the compiler pick evaluation order.
C++ can do only one thing. It cannot have evaluation order both specified and unspecified. It cannot evaluate both the LHS and the RHS of an assignment first.
So values must necessarily come into conflict, and battles over values are political, personal, and frequently nasty. Besides, what constitutes a technical argument? I say that Java has strict left-to-right evaluation, and I find that to be a technical argument - clearly the Java designers made this a conscious choice.
But others dismiss this with "why would we want C++ to be like Java?" Or conversely, people claim to find that some code can run 4% faster when order is not specified, and I say that I don't care.
And there is nothing in your problem specification to say that the inserts should happen in any particular order.
And there is nothing in your problem specification to say that the inserts should happen in any particular order.What is the "more correct" alternative? Show me how to write that same code in a way that is as clear and concise as this, which doesn't provoke undefined behavior.
auto inserts = {v.insert(v.end(), args)...};
If you're writing already complicated expressions, why complicate them further by making them order-dependent?
Am 12.07.2016 um 18:15 schrieb 'Edward Catmur' via ISO C++ Standard - Future Proposals:
And there is nothing in your problem specification to say that the inserts should happen in any particular order.I shouldn't have to look up the specification to know what the code is supposed to do.
What matters is what the intention of the author was and whether it matches what we read into it. Whichever the intention was it's obviously not expressed unambiguously. As long as the code makes the author's intentions ambiguous it is not a win for code clarity.
That makes it an initializer_list, meaning the values are const, meaning you cannot move them out.auto inserts = {v.insert(v.end(), args)...};
Just saying.
If you're writing already complicated expressions, why complicate them further by making them order-dependent?No system becomes more complicated or harder to understand by removing degrees of freedom.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c230a40c-6c47-3af8-543c-5c45c301b6d3%40gmail.com.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4ddc5467-9d40-87ad-fca9-dd61e4bc6ec9%40gmail.com.
Am 12.07.2016 um 19:03 schrieb Ren Industries:
The fact you continually assert this without evidence as if it is fact is what truly "beggars belief".People also constantly assert without evidence that this is somehow "removing expresiveness" from the language. I have asked in the past and now again for code examples that clearly, without doubt, expresses that the author's intention was *deliberately* for code to be order-independent and not just a lucky side effect of how the language works. And by example I do not mean "I just wrote an expression and it happens to not depend on order of evaluation". No, I mean "I wrote this expression and I *intentionally* require it to be order independent because the future of the universe depends on it".
Fact is human brains are very bad at doing (or imagining) multiple things happening at the same time which is why multithreading is such a hard problem. It is easier to go through something step by step than jumping around wildly or even doing things in parallel. Having a fixed order makes it easier to understand the solution because we can begin at one determined side of the expression and go through it one step at a time.
On Tue, Jul 12, 2016 at 8:21 PM, Miro Knejp <miro....@gmail.com> wrote:
Am 12.07.2016 um 19:03 schrieb Ren Industries:
The fact you continually assert this without evidence as if it is fact is what truly "beggars belief".People also constantly assert without evidence that this is somehow "removing expresiveness" from the language. I have asked in the past and now again for code examples that clearly, without doubt, expresses that the author's intention was *deliberately* for code to be order-independent and not just a lucky side effect of how the language works. And by example I do not mean "I just wrote an expression and it happens to not depend on order of evaluation". No, I mean "I wrote this expression and I *intentionally* require it to be order independent because the future of the universe depends on it".
Any time anyone has written code to use the parallel mode extensions of libstdc++.
Fact is human brains are very bad at doing (or imagining) multiple things happening at the same time which is why multithreading is such a hard problem. It is easier to go through something step by step than jumping around wildly or even doing things in parallel. Having a fixed order makes it easier to understand the solution because we can begin at one determined side of the expression and go through it one step at a time.
We're going to have to get better at it, because the 4GHz clock limit isn't going away any time soon. I don't want to see C++ lose a natural way to express soft parallelism because of poor choices made by programmers who still remember the era of the free lunch.
On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmck...@gmail.com> wrote:
On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.That sounds like a performance nightmare.
I've heard a lot of "sounds like" out of people defending the undefined order rules. I've heard far less "certainly is". Is there any genuine evidence of this "performance nightmare", or is it just fear of the unknown?
I can't speak for anyone else. In my case it is induction from observations that many existing optimizations depend to some extent on breaking naive intuitions of ordering.How many compilers actually use the undefined evaluation order rules to optimize code? Do they re-order expressions based on what is best for that specific expression? Or do they always evaluate expressions in an arbitrary order? Because if such flexibility is not actually making code faster, then the variance is pointless and should be done away with.
It does not matter whether compilers are currently able to exploit their freedom. The free lunch is over. Clock speeds are not getting any faster. If there is any prospect of the freedom being useful in future then it should be retained until we know for sure one way or the other, especially if new instructions could help compilers exploit it.
On Tue, Jul 12, 2016 at 1:12 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:Please look at the technical arguments instead of calling people who disagree with you "irrational".It's not a matter of technical arguments, it's a matter of values (as you say). Science can tell you how to accomplish what you want, but it can't tell you what to want. For me, the values involved in having a programming language that is simply specified and deterministic and consistent far outweigh the possible optimization benefit in letting the compiler pick evaluation order. SImilarly, I find negative value in having unspecified behavior in order to force programmers to be hyper-vigilant to avoid error. I find negative value in the notion that unspecified order adds expressiveness.
C++ can do only one thing. It cannot have evaluation order both specified and unspecified. It cannot evaluate both the LHS and the RHS of an assignment first. So values must necessarily come into conflict, and battles over values are political, personal, and frequently nasty.
Besides, what constitutes a technical argument? I say that Java has strict left-to-right evaluation, and I find that to be a technical argument - clearly the Java designers made this a conscious choice. But others dismiss this with "why would we want C++ to be like Java?" Or conversely, people claim to find that some code can run 4% faster when order is not specified, and I say that I don't care.
Ultimately, my goal is to not be silent, so that when C++ goes the wrong (IMO) way, no one can say that this was done with the acquiescence of the entire C++ community.
And for your amusement, or horror:
struct A { }; A f(); A g();
void operator<<(A, A);
auto shfpointer = (void(*)(A, A))&operator<<;
operator<<(f(), g()); // must evaluate f() then g()
shfpointer(f(), g()); // can evaluate f() and g() in either order
People also constantly assert without evidence that this is somehow "removing expresiveness" from the language. I have asked in the past and now again for code examples that clearly, without doubt, expresses that the author's intention was *deliberately* for code to be order-independent and not just a lucky side effect of how the language works. And by example I do not mean "I just wrote an expression and it happens to not depend on order of evaluation". No, I mean "I wrote this expression and I *intentionally* require it to be order independent because the future of the universe depends on it".
If I'm reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf correctly (§6.4), it's only "f() << g()" that gets the sequenced-before edge. "operator<<(f(), g())" is written like a function call and so doesn't. You're welcome to retarget your horror to that difference. ;-)
Take the expression int a = b() + c() + d();Where b(), c() and d() return ints. When I see an expression like that, I as the reader expect it to be both commutative and associative. And in C++ today, it would be buggy code if the result were dependent on the order of evaluation. I could, for instance, rewrite it as:int e = c() + d()int a = b() + e;If the evaluation order is defined, I as a code maintainer can no longer do this transformation without looking at b(), c(), d() to make sure they are completely independent, because it is impossible to tell just from the original expression if is dependent on the order of evaluation or not. In the evaluation order dependent world, this refactoring is fragile and may break code.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbttJcPLe%2BS5AaOhmA0WKj6Y8%2BJBNqtaD7zFRKBNQOahg%40mail.gmail.com.
This applies equally well to right-to-left order (which is currently Clang's ordering, I believe). It in no way proves that left-to-right is somehow the only correct way.
I do think it's on the table to make the sequencing stricter for C++20, once folks have had time to investigate more of the implications. The change for C++17 was just cautious.
In C++ today this code is not associative. For example, even if all functions return int values, if b() returns 1, c() returns -1, and d() returns INT_MIN, reordering the computations (at the source level) to add c() and d() before adding b() would result in undefined behavior. If the functions return float values, reordering can lead to utterly wrong results.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DVTP8gZZ_2L4OMytLVefzYx7dUs-JQ_CuGanRD4CVAGg%40mail.gmail.com.
In other words, when you write code that doesn't obey the rules of commutativity and associativity, you make it harder for humans to understand. Great point!
On 12 July 2016 at 14:21, Miro Knejp <miro....@gmail.com> wrote:
People also constantly assert without evidence that this is somehow "removing expresiveness" from the language. I have asked in the past and now again for code examples that clearly, without doubt, expresses that the author's intention was *deliberately* for code to be order-independent and not just a lucky side effect of how the language works. And by example I do not mean "I just wrote an expression and it happens to not depend on order of evaluation". No, I mean "I wrote this expression and I *intentionally* require it to be order independent because the future of the universe depends on it".
When you compile, do you ever turn on optimizations? If so, why, as they are known to make buggy code less deterministic.
I want the correct code I write to be as fast as possible.
I call code that is accidentally dependent on the order of evaluation a bug. You want to call it a feature. If it is a feature people will write both deliberate code and accidental code that takes advantage of it, since it is impossible to tell the difference between the two.
Take the expression int a = b() + c() + d();
Where b(), c() and d() return ints. When I see an expression like that, I as the reader expect it to be both commutative and associative. And in C++ today, it would be buggy code if the result were dependent on the order of evaluation. I could, for instance, rewrite it as:
int e = c() + d()int a = b() + e;
If the evaluation order is defined, I as a code maintainer can no longer do this transformation without looking at b(), c(), d() to make sure they are completely independent, because it is impossible to tell just from the original expression if is dependent on the order of evaluation or not. In the evaluation order dependent world, this refactoring is fragile and may break code.
I've made this comment in the past, and did not expect the discussion to come back two weeks after we voted on the issue, but as a complement to Nevin's comment, I'm glad, from a code review perpsective, that code written as x = h(f(),g()); where there are side-effects to f() and g() can be considered as something that's buggy and requires rewriting, not as something potentially correct and that needs to be investigated.
That makes it an initializer_list, meaning the values are const, meaning you cannot move them out.auto inserts = {v.insert(v.end(), args)...};
Just saying.
Moving iterators?
I feel like the real issue is the absence of a way for the author to convene whether the order mattered in the first place or not, regardless of whether evaluation order is fixed or not.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaQKCdgo-HjAAH6KcLZ6Xghetv1PbW9f1TT2ypN_vHi7A%40mail.gmail.com.
In a language with a properly defined evaluation order, the following code works as obviously as it reads.
I've said it before - C and C++ programmers have developed Stockholm Syndrome with respect to evaluation order. The rules have been wrong for so long that programmers have come to believe that this is the way they must be, and then accuse reasonable-looking code of being broken, stupid, error-prone, and lazy when it's really the language that's that way.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZfEEs_Nmr4xZg76caDsH0gVb07qmNM9G_5rFXNj%3DngFw%40mail.gmail.com.
On Tue, Jul 12, 2016 at 4:38 PM, Nevin Liber <ne...@eviloverlord.com> wrote:In other words, when you write code that doesn't obey the rules of commutativity and associativity, you make it harder for humans to understand. Great point!
When you apply the incorrect mental model to a programming language, you will fail to understand the program.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9dd07c8c-70bb-455b-8062-7350306fccf3%40isocpp.org.
You also should moderate your language. :) Most people here are rational and not stupid, but they may value different things than you do. For example, some people value the 4% speed improvement that http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf demonstrated a compiler could achieve on some programs by fiddling intelligently with the evaluation order. It's not obvious to me that this 4% is worth the bugs it implies, but it's also not obvious to me that it's not.
So an oracle or perfect PGO would get that 4% in its entirety. And that's just a binary choice between LTR and RTL, not full permutation of ordering.
In the example, the values of the initializer_list are iterators. I'm questioning whether moving an iterator (at least one to a normal container) is ever something one would wish to do.
On Tue, Jul 12, 2016 at 6:12 AM, Nicol Bolas <jmck...@gmail.com> wrote:On Monday, July 11, 2016 at 8:27:41 PM UTC-4, Edward Catmur wrote:On 11 Jul 2016 9:36 p.m., "Hyman Rosen" <hyman...@gmail.com> wrote:
>
> The right decision is strict left-to-right order of evaluation for all expressions, with side-effects fully completed as they are evaluated.That sounds like a performance nightmare.
I've heard a lot of "sounds like" out of people defending the undefined order rules. I've heard far less "certainly is". Is there any genuine evidence of this "performance nightmare", or is it just fear of the unknown?I can't speak for anyone else. In my case it is induction from observations that many existing optimizations depend to some extent on breaking naive intuitions of ordering.How many compilers actually use the undefined evaluation order rules to optimize code? Do they re-order expressions based on what is best for that specific expression? Or do they always evaluate expressions in an arbitrary order? Because if such flexibility is not actually making code faster, then the variance is pointless and should be done away with.It does not matter whether compilers are currently able to exploit their freedom.
The free lunch is over. Clock speeds are not getting any faster. If there is any prospect of the freedom being useful in future then it should be retained until we know for sure one way or the other, especially if new instructions could help compilers exploit it.
> The reason for choosing strict left-to-right order is that it's trivial to explain, matches the order in which code is read, and matches other languages such as Java.
Any experienced user reads code blocks as a unit, just as any proficient reader of natural languages reads sentences and paragraphs in a single glance.
Let's pretend this was true (despite the undeniable fact that "experienced users" make these mistakes too).
So what? Are we supposed to restrict C++ to "experienced users" as you define it?It would be better to restrict C++ to experienced users than to make it useless to them.
On Tue, Jul 12, 2016 at 2:47 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>
>
> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
>>
>> You also should moderate your language. :) Most people here are rational
>> and not stupid, but they may value different things than you do. For
>> example, some people value the 4% speed improvement that
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
>> demonstrated a compiler could achieve on some programs by fiddling
>> intelligently with the evaluation order. It's not obvious to me that this 4%
>> is worth the bugs it implies, but it's also not obvious to me that it's not.
>
>
> What 4% improvement? The paper discussed a 4% variance. Performance changed
> plus or minus 4%, depending on the various conditions.
>
> Nowhere in that paper was it stated that undefined order caused a flat 4%
> speed improvement.
Right, the paper shows a +/-4% variance, meaning there's at least 4%
performance on the table for some programs if the optimizers can be
made smarter. In particular, if the optimizer can identify the
programs for which reversing the argument evaluation order causes a 4%
improvement, it could do that and get the 4% improvement.
Folks are worried about closing off that possibility. It's true that
optimizers haven't been taught to do this in the many years they've
been allowed to, but now there's evidence people should be looking
harder in this direction. If folks look over the next 3 years and
nothing materializes, that becomes a stronger argument to nail down
the left-to-right order in C++20.
On Tuesday, July 12, 2016 at 5:56:04 PM UTC-4, Jeffrey Yasskin wrote:On Tue, Jul 12, 2016 at 2:47 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>
>
> On Tuesday, July 12, 2016 at 1:12:44 PM UTC-4, Jeffrey Yasskin wrote:
>>
>> You also should moderate your language. :) Most people here are rational
>> and not stupid, but they may value different things than you do. For
>> example, some people value the 4% speed improvement that
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r2.pdf
>> demonstrated a compiler could achieve on some programs by fiddling
>> intelligently with the evaluation order. It's not obvious to me that this 4%
>> is worth the bugs it implies, but it's also not obvious to me that it's not.
>
>
> What 4% improvement? The paper discussed a 4% variance. Performance changed
> plus or minus 4%, depending on the various conditions.
>
> Nowhere in that paper was it stated that undefined order caused a flat 4%
> speed improvement.
Right, the paper shows a +/-4% variance, meaning there's at least 4%
performance on the table for some programs if the optimizers can be
made smarter. In particular, if the optimizer can identify the
programs for which reversing the argument evaluation order causes a 4%
improvement, it could do that and get the 4% improvement.
My point is that there are also cases where there is a 4% performance loss compared to LTR. That LTR gives up-to-4% better performance in some cases. If performance is the primary opposing argument, then that fact needs to be weighed as well.
Folks are worried about closing off that possibility. It's true that
optimizers haven't been taught to do this in the many years they've
been allowed to, but now there's evidence people should be looking
harder in this direction. If folks look over the next 3 years and
nothing materializes, that becomes a stronger argument to nail down
the left-to-right order in C++20.
If this was a firm promise that, if nobody has proven otherwise, then we'd close things up in C++20, I'd be fine with it. But it isn't.
The problem with this reasoning is that this argument will be no less valid in 2019 than it is in 2016. You can always say that in "3-5 years", compilers will take greater advantage of this.
What arguments can you use against this in 2019 that you couldn't in 2016? The only argument you can use is that it's 3 years later, but that's not a strong argument. After all, it's been 18 years since C++98, and these things have yet to materialize.
There's always going to be some excuse to keep kicking the can along. To put it off for another standard cycle. To say that we'll get those optimizations any year now.
What is the end-game here? What is the critical point where we can make this sort of things stop?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbRuuzTJ7NpFDHjiAK7ytM7o3CY2xR5bgMBvd9VsurXbg%40mail.gmail.com.
On Jul 12, 2016 7:27 PM, "Patrice Roy" <patr...@gmail.com> wrote:
> I look forward to reading your proposal.
Don't be disingenuous. You know very well that such a proposal would not pass. It is impossible to convince enough people that l-to-r should be adopted. The "but optimization!" folks hold too much sway. The fact that r-to-l for assignments passed in C++17 is further evidence that there is no hope. And then there are the people who just like the status quo.
I am just the lone crackpot shouting in the wilderness.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbP%2BoJvaNNc69DqPg2qcD9hEJZhMfLOaQQWV7We7-uGHQ%40mail.gmail.com.
There were debates in Oulu, and there were people for and against what you care so much about.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4445b47-0552-473d-a68c-2c97b7965ff3%40isocpp.org.
Note that this RTL for assignments was done like that to match the
associativity of the operator in question:
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZQy4gvUmYCcbxHHjNksEw9DeB-5kCx4_Q9PiS0%3DdccOw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_YO2RfUQGRJvEuhoFGtmp5vd-FHsjgOOfcL91r1V2YWw%40mail.gmail.com.
Discussions are not public (to leave people maximal freedom of expression), and they are held in subgroups as well as in plenary if needed (sometimes, it's just something simple or something that everyone agrees on).
In this specific case, the paper on expression ordering suggested fixing seven orderings (if my memory's correct) and only one was (highly) problematic in the eyes of many, including myself. The proposal was split, the other six (again, from memory) were accepted, and this one was not. The arguments for and against are well-known to those who read this list.
In the end, it's a consensus decision, and consensus was not reached for this part of the ordering proposal. As Jeffreay and others stated, should people care enough to try to convince the committee to revisit its position on this specific issue, there are mechanisms that allow this (NB Comments, for example, or a proposal targeted towards C++20).
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7572efc6-b6dd-4cd2-bdb0-039e9ae7157c%40isocpp.org.
That being said, instructor and teachers have a responsibility here, and the current rules can be taught (they have been for a while), just as new ones could. I think we should go for more objective arguments should this discussion continue. And I really would prefer to discuss over an actual proposal (it helps organize and focus discussions).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZCGY9VbBDxPrH_cCb%2Bokcc5nq5iMrJ8FwQax%2BLwusNtw%40mail.gmail.com.
Why would the simplicity of teaching anything matter more than anything else? IEEE 754 is incredibly hard to teach, with many odd nuances to it, yet it is used because those nuances lead to better results. Modeling after the mathematical concepts underlying the operations may lead to more difficult to teach, but also has clear benefits, as DV explained.
When you must teach someone that in a() << b(), a() is called before b(), in a() <<= b(), b() is called before a(), and in a() + b(), a() and b() can be called in either order, you are imposing a cognitive load of meaningless difference, and that will make the student quickly forget the rules. When you teach someone that in an expression, subexpressions are evaluated left-to-right, you impart a simple and universal rule that no one will forget.
They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.
They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.That's interesting. But then why not make the arguments evalued right to left then?Is it because everything else is left to right and having this particular case be right-to-left may cause confusion?
They found 2% penalty for LTR over RTL on one of the SPEC2006 tests.That's interesting. But then why not make the arguments evalued right to left then?Is it because everything else is left to right and having this particular case be right-to-left may cause confusion?
but "everything else" is not evaluated LTR.
Because it's the "happens before" order. When you write:
a() = b() = c() = d();
The c() = d() assignment happens first. So regardless of the order in which c()
and d() are called, I'd expect that the pair gets called before b().