Fergus Henderson <fjh@munta.cs.mu.OZ.AU> writes:

:Alexander Gootman <gtm@cer.nsk.su> writes:

:>int i=0, *p=&i;
:>inline void g(int& r) {i=r++; cout << "g(i): r=" << r << endl;}
:>inline void f(int n) {i=n;};
:>main() { cout << (i=i++) << ' ' << f(i) << ' ' << f(*p) << endl;
:>                  i=i++;
:>                  cout << "i=0;i=i++; : " << i << endl;
:>                  g(i);
:>}

:I'm completely mystified by this example.  What point are you
:trying to make here?

   Sorry, I maked mistakes in copying it :-(
   Right is the following:

#include <iostream.h>
int i=0, *p=&i;
inline int& g(int& r) {i=r++; return r;}
inline void f(int n) {i=n;}
main() { cout << (f(i++),i) << ' ' << (f((*p)++),i) << endl;
                  i=i++;
                  cout << "i=0;i=i++; : " << i << endl;
                  cout << "g(i): r=" << g(i) << endl;
                  return 0;
}


:"inline" is a compiler hint.
:It should not have any effect on sequence points or order of evalution.

Yes, and here it is also a hint for my readers: imagine somebody
found common parts and decided to factor it in (inline) functions.
Opposite also could be possible: manually inlining a call in some
mainstream place. The g() function shows also that double accessing
the same location cannot everywhere be seen by a compiler.
So, such actions currently can change order of evaluation.

:Operator overloading doesn't have anything to do with order of evaluation.

When one begins program developing with a built-in type and later changes
it to a user defined, operator=() and others become functions and thus
(slightly) change expression evaluation.

:--
:Fergus Henderson                     fjh@munta.cs.mu.OZ.AU


 I`ll try to repeat my point in reverse order:

  a) For a clarity and consecuence of the language it would be better
     if there were no extra difference between user-defined operator and
     built-in operator.
  b) Would it be true (currently it is not) there were no difference
     between calls of f() and g() in the test, and actually result is

0 0
i=0;i=i++; : 1
g(i): r=2

  c) A compiler must remember that difference, so is a user.

  e) An extra sequence point - after operands evaluation and
     before an operation seems close the gap while decreasing
     efficiency of code very slightly.

- Alexander A. Gootman    Novosibirsk, Russia