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

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
(e.g.
> > generate a compiler error when the variable IS read), so you would have
to
> > trust the function implementer that it indeed doesn't care about the
initial
> > 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_ );
>
> 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.

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

How can I tell from that that f changed the param?  There's absolutely NO
indication.
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
> enforced?
>
> Noel
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>