Understanding the as-if rule, "the program was executed as written"
Solution 1:
On Monday your boss comes into your office and says "I need file A on my desk by Thursday and file B on my desk on Friday". He first describes the things that he wants in file A and how he thinks you should do those and then describes the things he wants in file B.
In the mind of your boss, you will first do the things for file A, place that file on his desk on Thursday, then get to work on file B and finish that on Friday. But you realize that it would make more sense to start work on file B earlier - before file A even. There's no reason your boss has to know - all he cares about is receiving A on Thursday and B on Friday. You also realize that the way he suggested can be improved, so you take a slightly different approach to producing the required information.
In this analogy, the boss is some C++ code and you are the compiler. It is legal for the compiler to rearrange operations (work on the files in another order) as long as the observable behavior (putting files on the desk of the boss) is the same. Similarly, the compiler is free to do any transformations (using a different approach than the one described by the boss) on the code that preserve the observable behavior.
In particular, "as if the program was executed as written" means "as if you did the work exactly as your boss instructed you to" (even if you did something different).
Solution 2:
An important feature of the cited rule is that it specifies a minimal set of requirements for an implementation to be conforming, but in no way implies that those requirements will be sufficient for any particular application, nor that some applications won't need implementations to offer stronger guarantees. Suppose the procedure for performing and recording the results of a single test would be:
- Do the experiment.
- Write down the measured result.
- Unlock the safe
- Put the paper with the measurements in the safe.
- Lock the safe.
If one is given three tests to perform, one could perform the above five steps in order for each test, but either of the following sequences of steps might also be acceptable:
- Do experiment #1
- Write down the measured result on paper #1
- Do experiment #2
- Write down the measured result on paper #2
- Do experiment #3
- Write down the measured result on paper #3
- Unlock the safe
- Put paper #1 in the safe
- Put paper #2 in the safe
- Put paper #3 in the safe
- Lock the safe
or--to avoid having to keep track of three papers at once:
- Do experiment #1
- Write down the measured result on paper #1
- Unlock the safe
- Put paper #1 in the safe
- Do experiment #2
- Write down the measured result on paper #2
- Put paper #2 in the safe
- Do experiment #3
- Write down the measured result on paper #3
- Put paper #3 in the safe
- Lock the safe
If everything goes as expected, all three approaches would be equivalent. If, however, the second experiment could go awry and trash any papers that are lying on the desk, using the second approach would risk losing the results of the first experiment--an outcome that would not have occurred had the fully-detailed procedure been followed. Worse, if the third experiment goes really awry and trashes everything that isn't locked in the safe, the third approach would risk losing everything that was in the safe, even content unrelated to the experiments.
In some cases the second or third approach may be appropriate. In some, it wouldn't. Judging whether those approaches are appropriate would require knowledge of the risks posed by the experiments, the contents of the safe, and many other factors.
The authors of the Standard can't know everything necessary to judge what guarantees will be needed by what applications. Instead, they rely upon the producers and users of various implementations to recognize what guarantees will be needed to safely and effectively accomplish whatever needs to be done.