"Observable behaviour" and compiler freedom to eliminate/transform pieces c++ code
<p>After reading <a href="http://stackoverflow.com/questions/6624022/does-allocating-memory-and-then-releasing-constitute-a-side-effect-in-a-c-progr">this discussion</a> I realized that I almost totally misunderstand the matter :)</p>

<p>As the description of C++ abstract machine is not rigorous enough(comparing, for instance, with JVM specification), and if a precise answer isn't possible I would rather want to get informal clarifications about rules that reasonable "good" (non-malicious) implementation should follow.</p>

<p>The key concept of part 1.9 of the Standard addressing implementation freedom is so called as-if rule: </p>

<blockquote>
  <p>an implementation is free to disregard any requirement of this
  Standard as long as the result is as if the requirement had been
  obeyed, as far as can be determined from the observable behavior of
  the program.</p>
</blockquote>

<p>The term "observable behavior", according to the standard (I cite n3092), means the following:</p>

<blockquote>
  <p>— Access to volatile objects are evaluated strictly according to the
  rules of the abstract machine.</p>
  
  <p>— At program termination, all data written into files shall be
  identical to one of the possible results that execution of the program
  according to the abstract semantics would have produced.</p>
  
  <p>— The input and output dynamics of interactive devices shall take
  place in such a fashion that prompting output is actually delivered
  before a program waits for input. What constitutes an interactive
  device is implementation-defined.</p>
</blockquote>

<p>So, roughly speaking,  the order and operands of volatile access operations and io operations should be preserved; implementation may make arbitrary changes in the program which preserve these invariants (comparing to some allowed behaviour of the abstract c++ machine)</p>

<ol>
<li><p>Is it reasonable to expect that non-malicious implementation treates io operations wide enough (for instance, any system call from user code is treated as such operation)? (E.g. RAII mutex lock/unlock wouldn't be thrown away by compiler in case RAII wrapper contains no volatiles)</p></li>
<li><p>How deeply the "behavioral observation" should immerse from user-defined c++ program level into library/system calls? The question is, of course, only about library calls that <em>not intended</em> to have io/volatile access from the user viewpoint (e.g. as new/delete operations) but may (and usually does) access volatiles or io in the library/system <em>implementation</em>. Should the compiler treat such calls from the user viewpoint (and consider such side effects as <em>not observable</em>) or from "library" viewpoint (and consider the side effects as <em>observable</em>) ?</p></li>
<li><p>If I need to prevent some code from elimination by compiler, is it a good practice not to ask all the questions above and simply add (possibly fake) volatile access operations (wrap the actions needed to volatile methods and call them on volatile instances of my own classes) in any case that seems suspicious? </p></li>
<li><p>Or I'm totally wrong and the compiler is disallowed to remove any c++ code except of cases explicitly mentioned by the standard (as copy elimination)</p></li>
</ol>
