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

Groups > comp.lang.lisp > #33122 > unrolled thread

TIL: C++17 sequences assignment the wrong way.

Back to article view | Back to comp.lang.lisp

Contents

  TIL: C++17 sequences assignment the wrong way. Kaz Kylheku <847-115-0292@kylheku.com> - 2019-07-19 03:36 +0000
    Re: TIL: C++17 sequences assignment the wrong way. Barry Fishman <barry@ecubist.org> - 2019-07-19 10:14 -0400
      Re: TIL: C++17 sequences assignment the wrong way. Kaz Kylheku <847-115-0292@kylheku.com> - 2019-07-19 16:45 +0000
        Re: TIL: C++17 sequences assignment the wrong way. Barry Fishman <barry@ecubist.org> - 2019-07-19 15:55 -0400
    Re: TIL: C++17 sequences assignment the wrong way. Stefan Monnier <monnier@iro.umontreal.ca> - 2019-07-19 13:30 -0400
      Re: TIL: C++17 sequences assignment the wrong way. Kaz Kylheku <847-115-0292@kylheku.com> - 2019-07-19 18:44 +0000

#33122 — TIL: C++17 sequences assignment the wrong way.

C++17 adds a sequence point to assignment. E1 = E2 requires E2 to be
completely evaluated first, then E1.

Wow, what a jaw-droppingly moronic moment in computing history.

They had the right motivation to fix a flaw, at least in one small area,
and establish an order where there is chaos.

Then they drop the ball by making it backwards.

[toc] | [next] | [standalone]

#33123

On 2019-07-19 03:36:55 +00, Kaz Kylheku wrote:
> C++17 adds a sequence point to assignment. E1 = E2 requires E2 to be
> completely evaluated first, then E1.
>
> Wow, what a jaw-droppingly moronic moment in computing history.
>
> They had the right motivation to fix a flaw, at least in one small area,
> and establish an order where there is chaos.
>
> Then they drop the ball by making it backwards.

[Although I spent a long time using C++, I stopped using it a while back,
and my knowledge of the language has atrophied.]

I presume they were concerned about side effects in things like:

int *p = an_array_of_ints;
for (int i = 0; i < 3; i++) {
  *p++ = *p + 1;
}

I think any importance of the direction of such ordering is lost in a
language rooted in a time when compilers were not very good and side
effects were an important part of optimizing code.

I think the greater importance now on readability, security, and maybe
distributed programming techniques has made using such languages a bad
idea, irrespective of any new semantic tightening.

--
Barry Fishman

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

#33124

On 2019-07-19, Barry Fishman <barry@ecubist.org> wrote:
>
> On 2019-07-19 03:36:55 +00, Kaz Kylheku wrote:
>> C++17 adds a sequence point to assignment. E1 = E2 requires E2 to be
>> completely evaluated first, then E1.
>>
>> Wow, what a jaw-droppingly moronic moment in computing history.
>>
>> They had the right motivation to fix a flaw, at least in one small area,
>> and establish an order where there is chaos.
>>
>> Then they drop the ball by making it backwards.
>
> [Although I spent a long time using C++, I stopped using it a while back,
> and my knowledge of the language has atrophied.]
>
> I presume they were concerned about side effects in things like:
>
> int *p = an_array_of_ints;
> for (int i = 0; i < 3; i++) {
>   *p++ = *p + 1;
> }

In C++17, this will reliably calculate the prior value of *p + 1,
store it in *p, and increment p.

But under left-to-right, that can be done just fine:

  *p = *p++ + 1;

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

#33127

On 2019-07-19 16:45:11 +00, Kaz Kylheku wrote:
> On 2019-07-19, Barry Fishman <barry@ecubist.org> wrote:
>>
>> On 2019-07-19 03:36:55 +00, Kaz Kylheku wrote:
>>> C++17 adds a sequence point to assignment. E1 = E2 requires E2 to be
>>> completely evaluated first, then E1.
>>>
>>> Wow, what a jaw-droppingly moronic moment in computing history.
>>>
>>> They had the right motivation to fix a flaw, at least in one small area,
>>> and establish an order where there is chaos.
>>>
>>> Then they drop the ball by making it backwards.
>>
>> int *p = an_array_of_ints;
>> for (int i = 0; i < 3; i++) {
>>   *p++ = *p + 1;
>> }
>
> In C++17, this will reliably calculate the prior value of *p + 1,
> store it in *p, and increment p.
>
> But under left-to-right, that can be done just fine:
>
>   *p = *p++ + 1;

Yes.  But to my Infix language sense, this is less clear, especially
where the right hand side is more complex.

Also, I think infix assignment (ignoring side effects) usually makes more sense
in a right to left evaluation order.

In gcc and g++, although I am not sure if legal generally in C++17:

 b = a = 3;

as opposed to Lisp, where one would do:

(setq a 3 b a)

Or explicit ordered:

(setq b (setq a 3))

Personally I just try to avoid side effects (and C/C++).

--
Barry Fishman

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

#33125

> C++17 adds a sequence point to assignment.
> E1 = E2 requires E2 to be completely evaluated first, then E1.

Do you happen to have a reference to this part of the spec?
Even better would be to see the discussions that lead to this
entertaining choice.

Almost makes you pine for the good old days when the CL spec was
the go-to example of a bloated and complex language specification.


        Stefan

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

#33126

On 2019-07-19, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> C++17 adds a sequence point to assignment.
>> E1 = E2 requires E2 to be completely evaluated first, then E1.
>
> Do you happen to have a reference to this part of the spec?

8.5.18 ¶1 in the draft:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

By the way, I caught myself almost switching to a web browser to search
for the paragraph "pilcrow" symbol. Instead of that, I switched to
Japanese IME in Ubuntu and tried my luck with ぱらぐらふ
(pa-ra-gu-ra-fu). Sure enough, one of the completions/substitutions
offered was ¶. :)

Japanese IME: it's darn useful, not just for Japanese!

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.lisp

csiph-web