Sequencing

[Alvin]

Is there an elegant trick to enforce sequencing, so that fn1 is called
before fn2? C++17 seems to guarantee that for the shift operator but not
"+".


int fn() {
return fn1() + fn2();
}

[Christian Gollwitzer]

Am 11.03.17 um 11:23 schrieb Alvin:

int fn() {
auto t1 = fn1();
auto t2 = fn2();
return t1 + t2;
}

[Alf P. Steinbach]

On 11-Mar-17 11:23 AM, Alvin wrote:
> Is there an elegant trick to enforce sequencing, so that fn1 is called
> before fn2? C++17 seems to guarantee that for the shift operator but not
> "+".

I don't think the shift operators have such guarantee. However the built
in boolean operators, && and ||, have guaranteed short-circuit behavior;
the choice operator ?: guarantees that the unused value expression (of
the two) is not evaluated; and the comma operator provides sequencing.
There is also some slight sequencing guaranteed for plain assignment, =,
but since few people are aware of the details or even the general, it's
probably not a good idea to leverage that.

> int fn() {
> return fn1() + fn2();
> }

auto fn() -> int { int t = fn1(); return t + fn2(); }


Cheers & hth.,

- Alf

[Alvin]

On 2017-03-11 14:14, Alf P. Steinbach wrote:
> On 11-Mar-17 11:23 AM, Alvin wrote:
>> Is there an elegant trick to enforce sequencing, so that fn1 is called
>> before fn2? C++17 seems to guarantee that for the shift operator but not
>> "+".
>
> I don't think the shift operators have such guarantee.

C++17, P0145R3: Stricter expression evaluation order

<<<
Add a new paragraph 5.8/4 to section 5.8

The expression E1 is sequenced before the expression E2.
>>>

(Section 5.8 is "Shift operators".)

[Manfred]

It does not apply to the example ('+' operator), but in general the
comma operator (n4618 5.19) is explicitly meant to enforce sequencing of
expressions.

[Paavo Helde]

int fn2a(int x) {
return x+fn2();
}

int fn() {
return fn2a(fn1());
}

[Ben Bacarisse]

or, in sufficiently modern C++, using an anonymous function:

int fn() { return [](auto r){ return r + fn2(); }(fn1());

There's enough noise (all those (){[](){()}(())}s) that it's only good
for illustration but at least g++ compiles it down to minimal code (with
-O2).

--
Ben.

[Richard]

[Please do not mail me a copy of your followup]

Alvin <Al...@invalid.invalid> spake the secret code
<oa0j2j$mv1$1...@dont-email.me> thusly:

I wouldn't want commutative math operations to enforce an ordering
because that is an unwarranted imposition on the compiler IMO.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Alvin]

template<class T>
T sequenced_sum(std::initializer_list<T> l) {
return std::accumulate(l.begin(), l.end(), 0);
}

int fn() {
return sequenced_sum({ fn1(), fn2() });
}

[Öö Tiib]

Other suggestions in this thread seemed better-looking.

[Alvin]

For 2 functions I would probably use the versions with one or two
temporary variables. For more, this is IMHO the best version so far.

[Alf P. Steinbach]

Uhm, well. How often does one have a sum of N different argument
expressions, which all have side effects so that they must be evaluated
in order?

For a reasonable number of such arguments, say f1(), f2() and f3() all
with side-effects, which is a case that for me has occurred less than 1
time in 35 years, I'd just do

int sum = 0;
for( int x : {f1(), f2(), f3()} ) { sum += x; }

But then, I prefer to not use STL algorithms where similar size directly
expressed code can do it. Because with the directly expressed code one
doesn't have to know or look up details about the STL algorithm in
question. And I tend to forget such details.


Cheers!,

- Alf

[Daniel]

On Monday, March 13, 2017 at 3:15:17 PM UTC-4, Alf P. Steinbach wrote:
>
> But then, I prefer to not use STL algorithms where similar size directly
> expressed code can do it. Because with the directly expressed code one
> doesn't have to know or look up details about the STL algorithm in
> question. And I tend to forget such details.
>

Emphatic agreement!

Daniel