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

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-04 17:48:41

----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Sunday, May 04, 2003 3:43 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance

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

It DOES affect the caller, since x was modified internally inside f.

int & f(int &x)
{
    x++;
    return(x);
}

int x;
int &y = f(x);

What indication is there that x was changed inside of f?

int * f(int *x)
{
    *x++;
    return(x);
}

int x;
int *y = f(&x);

Again, what indication is there that x was modified internally?  How do I
know that what's being returned isn't being allocated by f?  You can't tell
just by looking at the call, you have to go track down the definition of the
function.

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

Like I've said, the system does require that the programmer use the objects
properly.  BUT, assuming they are used properly, just like we assume that
when we pass a const object it's not being const_cast, then it tells you for
sure that f is dependent on the value inside x and y, so they have to be
initialized to something, AND, it tells you that the values in x and y may
change.

>
> > > So, why opt for out parameters that aren't really out parameters when
a
> > > return value suffices?
> > >

return values don't suffice in all cases, as I've pointed out.

> > > Also, wouldn't c_in be more useful than c_out since c_in /can/ be
> > > enforced?
>

Our definitions of c_in are different, I'm using bad naming in this regard,
it should be something that indicates that ownership of the object is
changing hands.  For your version of c_in, I wouldn't want the common case
to have to be decorated.  In only params are the most common.

void f(const CObj &o)
{
    cout << o << endl;
}

Something like that, I think that's your version of an in param.  I wouldn't
want to have to decorate all of those.  I want the ones that are the odd
case decorated, so it's explicit that, hey, this isn't the common case, this
function IS going to modify these parameters, so heads up.

> You missed these questions.
>
> Noel
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>