"David Ching" <dc@remove-this.dcsoft.com> wrote in message
news:_gIsj.10927$J41.7974@newssvr14.news.prodigy.net...
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:9j46r3tpo220t0gc6cfi539duviu3nslfh@4ax.com...
In general, it can't, because it has no way of knowing what the
functions
do. Here is my example again, only without the bodies, which may be all
the
compiler can see:
struct T
{
// ++x;
T& operator++();
// x++;
T operator++(int);
};
Even if the bodies were available, the compiler would have to determine
they are semantically equivalent down to side-effects in order to apply
the
proposed optimization.
Does anyone have a good illustration of different side-effects of ++i vs.
i++? With the semantics of both to be return the value and increment (or
in the reverse order), I can't think of one. At first glance, this seems
a case where the optimization cannot be performed to give freedom that
will never be used.
-- David
If I ever get an app performing to the point that I'm considering the
performance benefits of ++i over i++ I'll consider my ascension complete
:-))
As to the earlier statement that "there is no reason to cling to i++";
yes, there is. I have better things to spend time thinking about that
will bring me greater benefit for the time spent.