Re: [boost] Re: in/out parameters, codingstylesandmaintenance

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
> indication.

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:

  int x;
  int y;

  f( in_out( x ), in_out( y ) ); // how do I know what f is doing with x
and y?

> > 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.

Noel