RE: [boost] operator++

From: Erdei, András (ccg_at_[hidden])
Date: 2000-10-11 05:59:55

> Doesn't this 'optimization' conflict with the return value optimization?

  No. OTOH IMHO the original code may disallow return
value optimization.

> Specifically, by not using a named tmp to hold the value, but
> constructing it directly in the return statement, aren't you telling the
> compiler to optimize away the (local occurrence of) proxy's destructor? 

  No.

> Of course the destructor for the returned object will execute at _some_
> later point, incrementing real at that time, but my personal opinion is
> to opt for the certainty that the side effect of incrementing T _must_
> happen by the conclusion of the ++ function.

  The opposite -- in conforming code you can't rely
on the compiler doing the increment at any particular point
during the evaluation of the expression. e.g.

  int i = 0 ;
  int j = i++ + i++ ; // j can be anything

> I'd also want to run some timing tests to see if calling
> uncaught_exception() is really faster than making a temporary copy or
> two of the underlying type.

  I have to admit, i haven't tought about the
performance of uncaught_exception() -- OTOH this
technique is really valuable when T is large
(T()/~T() is nontrivial), so whatever time
uncaught_exception() takes, you can have Ts
for which it's irrelevant. (In theory; in practice
it's rare to have a post++ for large objects
but it's partially because performance
considerations :O)

  Br,
  Andras