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
> > > 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
> > 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
> > 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)
int &y = f(x);
What indication is there that x was changed inside of f?
int * f(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
> > int &y = f(&x);
> > still no indication of what f is doing with x, just that it wants a
> 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
> > > So, why opt for out parameters that aren't really out parameters when
> > > 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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk