RE: [boost] operator++

From: Erdei, András (ccg_at_[hidden])
Date: 2000-10-11 10:30:56

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

>     int j = i.increment() + i.increment();

The difference between i.operator++(int) (or
operator++(i,int)) and i++ is just syntactical.

<snip>
>but I
>(personally) would expect that any side effects that happened _within_
>the increment() function would be complete when it returned. 
<snip>

  IMHO if you access an object between the
time it is modified and the first subsequent 
sequence point, the resulting behavior is undefined,
so in your example j can still be anything.

> But to go back to the return value optimization question, aren't we
> looking at two possible ways the compiler can generate the
> [pseudo-]code?
<snip pseudocode>
>If I understand as much (little?) as I think I do, the statement
>
>	return proxy( t );
>
> guarantees that option 1 is what the compiler will use. But can we be
> sure that the __result destructor will be complete by the sequence point
> which immediately follows this function call? Or might it hang around
> until the sequence point at the next semicolon?

  Sorry, i don't grok your pseudocode (haven't read Lippmans book);
but if i understand you correctly: no, as a temporary it *has to* hang 
around, until the full expression is evaluated.

> [2]
> operator ++ ( proxy & __result, T& real, int )
> {
>     proxy __tmp( real );      // construct local temporary
>     __result::proxy( __tmp );  // copy ctor into return value

  If i understand your pseudo-code correctly:
proxy has no copy ctor, so the compiler can't
call it.

> I'd be afraid the code might decay
> under maintenance. I feel that's less of a danger with the slow-but-sure
> implementation you suggest replacing.

  You can be right, although i don't see
maintenance problems here; i see some drawbacks
(as mentioned earlier), and some advantages
(besides the speed gain), e.g. that this
version does not depend on the existence of
the copy ctor for T.

  Br,
  Andras