|
Boost : |
From: Lois Goldthwaite (loisg_at_[hidden])
Date: 2000-10-11 05:26:32
Doesn't this 'optimization' conflict with the 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?
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.
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.
Not-really-competent-to-masquerade-as-a-core-language-lawyer-ly yours,
Lois
"Erdei, András" wrote:
>
> [i've been only reading this group for two days,
> so this might be silly -- forgive/flame me]
>
> I've followed the link in a recent post
>
> > http://www.boost.org/libs/utility/operators.htm
> >
> and found operator++ implemented as
>
> // incrementable and decrementable contributed by Jeremy Siek
>
> friend T operator++(T& x, int)
> {
> incrementable_type tmp(x);
> ++x;
> return tmp;
> }
>
> a more efficient implemetation can be (stripped off
> the template stuff):
>
> class proxy
> {
> public :
> operator T const & ( void ) { return real ; }
> ~proxy() { if ( ! std::uncaught_exception() ) ++real ; } ;
> private :
> friend proxy operator++( T & , int ) ;
> proxy( T & real ) : real( real ) {} ;
> T & real ;
> } ;
>
> proxy
> operator++( T & t , int )
> {
> return proxy( t ) ;
> }
>
> I've tried to search eGroups to see if this was already
> discussed and for some reason rejected, but failed to
> find it if there was a discussion on this.
>
> Has this implementation been considered?
>
> TIA
> Andras
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk