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
> 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?
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk