From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-04 17:43:29
"Justin M. Lewis" wrote:
> > Right. The only way I can think of to enforce this would be to use
> > return from the function. For example, rather than:
> > void f( out< T > p_ );
> > use:
> > T f();
> > If, for some reason you T shouldn't be returned directly (eg it's large
> > or not copyable), either of the following can be used:
> > ptr< T > f();
> > ref< T > f();
> You're STILL modifying it through the param, and you see no indication of
> that, and you have no obligation to set it equal to the param.
That's right, because it's an out parameter. Am I missing something?
> int x;
> int *y = f(x);
> How can I tell from that that f changed the param? There's absolutely NO
It doesn't matter what f does with x since it won't affect the callee.
> int &y = f(&x);
> still no indication of what f is doing with x, just that it wants a pointer.
Many people use this convention as advertising that f will change x. It
does exactly what the proposed in_out does.
Using the proposed classes:
f( in_out( x ), in_out( y ) ); // how do I know what f is doing with x
> > So, why opt for out parameters that aren't really out parameters when a
> > return value suffices?
> > Also, wouldn't c_in be more useful than c_out since c_in /can/ be
> > enforced?
You missed these questions.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk