[boost] Re: FC++ Formal review is now in progress (2/13-2/23)

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-02-19 01:29:01

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> wrote in message
news:c10gfp$qi0$1_at_sea.gmane.org...
[snip]

> 4) Referencial integrity is anyway tricky enough to break even into a
> library specially designed to protect it.
> For example, FC++ uses  reference to const objects in order to avoid
mutable
> arguments, all in the name of referencial integrity. However, a "const&"
> parameter is not totally inmune to such problems the way a _true_ by-value
> parameter is, because it is after all still a reference, and references
> alias.
> Consider the following aparently contrived example:
>
> inline point transform ( point const& p )
> {
>   return point(2.0* p.x * p.y, 0.5 * p.x * p.y);
> }
> void foo()
> {
>   point p (..whatever...);
>   p = transform(p);
> }
>
> On many C++ implementations, the code above will yield an incorrect result
> because the return object will actually be constructed in place, producing
> an actual code equivalent to:
>
> p.x  = 2.0 * p.x * p.y ;
> p.y = 0.5 * p.x * p.y ;
>
> and you can see how the aliasing resulted in the _argument_ "p.x" being
> modified inside the function.
>
> That example is not too uncommon because any non-linear transformation
that
> use a linear combination of the coordinates can fail because of the
aliasing
> if a const& parameter is used instead of a true by-value argument.

Please educate me, is that really legal for a C++ implementation to do what
you're saying?

br

Thorsten