C++

Forum

 
Order of execution done by the compiler/implementation

frek (576)
Hi all,

I know that the code snipped below is wrong based on C++ rules, but do you have something in mind resembling it to demonstrate the difference between the order of instructions execution we expect and what the compiler does?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
#include <iostream>

void f() {
    std::cout <<"f() called\n";
}

void g() {
    std::cout <<"g() called\n";
}

void test(f(), g()) { }

int main() {
    test(f(), g());
}
Last edited on
kbw (9488)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
#include <iostream>

int f() {
    std::cout <<"f() called\n";
    return 0;
}

int g() {
    std::cout <<"g() called\n";
    return 0;
}

void test(int, int) {
}

int main() {
    test(f(), g());
}


Also: https://godbolt.org/z/hcvcsTTzG
Last edited on
JLBorges (13770)
With the corrected code, it is not wrong. Just indeterminately sequenced:
either f() will complete before g(), or g() will complete before f(); but their evaluations will not overlap.

15) In a function call, value computations and side effects of the initialization of every parameter are indeterminately sequenced with respect to value computations and side effects of any other parameter.
https://en.cppreference.com/w/cpp/language/eval_order#Rules
seeplus (6591)
Why in 2022 do we still have aspects of C++ unrelated to the processor that are still marked as undefined or unspecified? Surely by now all non-specific processor operations should be defined. I realise that different people have different views as to how some expressions should be evaluated - but surely that's the role of the C++ standards committee to decide on things like this - not do a symbolic shrug of the shoulders and allow such things just because they won't take the decisions.
salem c (3700)
A long time ago in a forum far far away....

I posted https://www.dreamincode.net/forums/topic/177775-comma-operator/page__view__findpost__p__1042539

> Why in 2022 do we still have aspects of C++ unrelated to the processor that are still marked as undefined or unspecified?
Because trying to specify it would add 100's of pages of arcane runes to the standards.
Which compiler writers would have to implement and test against.
And people would write all manner of bug reports for all the weird edge cases they find.
And for what?
JLBorges (13770)

> Why in 2022 do we still have aspects of C++ unrelated to the processor
> that are still marked as undefined or unspecified?

From the LLVM Blog:
Undefined behaviour exists in C-based languages because the designers of C wanted it to be an extremely efficient low-level programming language. In contrast, languages like Java (and many other 'safe' languages) have eschewed undefined behaviour because they want safe and reproducible behaviour across implementations, and willing to sacrifice performance to get it.


You may want to read this part:
... it would be helpful to consider a few specific cases of undefined behaviour, and talk about how each enables better performance than a safe language like Java. You can look at this either as "optimizations enabled" by the class of undefined behaviour or as the "overhead avoided" that would be required to make each case defined. While the compiler optimizer could eliminate some of these overheads some of the time, to do so in general (for every case) would require solving the halting problem and many other "interesting challenges".
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
seeplus (6591)
I was referring in my post above really to evaluation order - but I didn't word my post that carefully so that it's meaning was potentially unspecified.

Certainly I fully accept that use of uninitialised variables, signed overflow, oversized shifts, out of bounds array access etc etc etc are not things to be defined in the standard - other than as being not defined.

But as to my main thought re evaluation order - surely this can be defined in all cases as opposed to leaving it to the compiler writers to decide?


Topic archived. No new replies allowed.