57

I am trying to understand the as-if rule. According to cppreference:

The as-if rule
Allows any and all code transformations that do not change the observable behavior of the program

Explanation
The C++ compiler is permitted to perform any changes to the program as long as the following remains true: [...]

It is hard for me to understand the second tip of the Explanation section:

2) At program termination, data written to files is exactly as if the program was executed as written.

I just don't understand what "the program was executed as written" means.

TrebledJ
  • 8,713
  • 7
  • 26
  • 48
poohRui
  • 613
  • 5
  • 9
  • 13
    It means that compilers are not allowed to make optimisations that would change any output (with the exception of RVO). – Bathsheba Jun 28 '19 at 07:27
  • I'd suggest https://stackoverflow.com/questions/15718262/what-exactly-is-the-as-if-rule as duplicate. But maybe it doesn't answer the particular question well enough. – Max Langhof Jun 28 '19 at 07:51
  • @Aconcagua What do you think is the "as written behavior" in that case? If the order of outputs is undefined in your "as written" program (which it is by the sound of your description) then there is no requirement on the order of outputs of any concrete compilation of that program. – Max Langhof Jun 28 '19 at 07:53
  • It's saying that file output is a visible side effect and therefore cannot be optimised out or order changed. – Richard Critten Jun 28 '19 at 07:57
  • 3
    [Here is nice demo](https://youtu.be/bSkpMdDe4g4) what "As if" rule can do. IMO this is best way to understand that. – Marek R Jun 28 '19 at 08:04
  • 6
    @Aconcagua I very much agree - but it is worth being aware that there are some people who find it impossible to learn from a few lines of text and find a video *much* easier. – Martin Bonner supports Monica Jun 28 '19 at 09:45
  • @MartinBonner that's true, there are many, many people who prefer videos to text. When SO launches a video answer site, they can go there. – alexis Jun 30 '19 at 07:49

2 Answers2

143

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).

Max Langhof
  • 23,383
  • 5
  • 39
  • 72
15

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:

  1. Do the experiment.
  2. Write down the measured result.
  3. Unlock the safe
  4. Put the paper with the measurements in the safe.
  5. 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:

  1. Do experiment #1
  2. Write down the measured result on paper #1
  3. Do experiment #2
  4. Write down the measured result on paper #2
  5. Do experiment #3
  6. Write down the measured result on paper #3
  7. Unlock the safe
  8. Put paper #1 in the safe
  9. Put paper #2 in the safe
  10. Put paper #3 in the safe
  11. Lock the safe

or--to avoid having to keep track of three papers at once:

  1. Do experiment #1
  2. Write down the measured result on paper #1
  3. Unlock the safe
  4. Put paper #1 in the safe
  5. Do experiment #2
  6. Write down the measured result on paper #2
  7. Put paper #2 in the safe
  8. Do experiment #3
  9. Write down the measured result on paper #3
  10. Put paper #3 in the safe
  11. 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.

supercat
  • 77,689
  • 9
  • 166
  • 211