From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-04 15:30:08
----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Sunday, May 04, 2003 9:52 AM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance
> Floris van den Berg wrote:
> > It can be usefull i guess. If you want to show in your sourcecode that a
> > function doesn't care about an initial value in your parameter you'd use
> > c_out, otherwise c_in_out. But it's impossible to enforce such a thing
> > generate a compiler error when the variable IS read), so you would have
> > trust the function implementer that it indeed doesn't care about the
> > value and so that it doesn't read it.
> 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_ );
> 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.
int *y = f(x);
How can I tell from that that f changed the param? There's absolutely NO
int &y = f(&x);
still no indication of what f is doing with x, just that it wants a pointer.
> 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
> 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