Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-10 16:20:49


----- Original Message -----
From: "Gary Powell" <Gary.Powell_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, October 10, 2000 4:50 PM
Subject: RE: [boost] operator++

> > [i've been only reading this group for two days,
> > so this might be silly -- forgive/flame me]
> No way! This is sooo cool.
> The only question I have is whether by doing this "out of order" breaks
some
> other requirement of operator++(int); Otherwise I'm off to update my code.
>
> BTW where did you dream this bit up?
>
> Yours,
> -gary-
>
> gary.powell_at_[hidden]
>
> PS
> In case you didn't follow the code, as I read it the proxy allows any
> assignment to happen before the increment thus avoiding the need of a
> secondary construction of the object of type T. And as a bonus if there
> isn't an assignment as in for(Type i; i test; i++) vs ++i, it has the same
> level of efficency! (assuming that the compiler does at least the inlining
> correctly.)

Aside from the un-portability of uncaught_exception(), there's another
problem with this optimization. It's a general lesson you have to learn
about proxy objects: there's no way to make them absolutely transparent in
C++. In particular, since they rely on an implicit conversion to translate
the proxy into the target type, no further implicit conversions can be
applied by the compiler. That means this won't compile with the
optimization, though it should:

int f(OtherType);
struct OtherType {
   OtherType(const Type&);
   ...
};

Type i;
int x = f(i++);

today-is-tuesday-so-you-can't-get-something-for-nothing-ly y'rs,
dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk