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

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

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

> "Justin M. Lewis" wrote:
> >
> > Pull from your experience as a programmer and think, you've certainly
> > encountered places where you're passing polymorphics objects around by
> > reference or by pointer, calling member functions inside of them that
would
> > be modifying their internal state.  And, while you may not use
non-copyable
> > objects very often, a large part of what I do at work is dependent on
> > non-copyable objects that I'd like to be able to pass to functions to
work
> > with.
>
> I think many solutions have been given to this as well.  Here are some
> for those that don't like pointers (again):
>
>   void f( dumb_ref< T const > in_ );
>   void f( dumb_ref< T > inOut_ );
>   dumb_ref< T > f(); // out
>

Again, your version of out params is either requiring allocation inside f,
or that f is a member function and what it's returning is data internal to
the object.  And, as I keep saying, out params would be ANY case where you
pass data to a function that modifies the data internally, ignoring the
current state of the object.  In that case, your out param function would
have to be more like

dumb_ref< T > f(dumb_ref< T > t); // out

> Don't these address the problem of tracking down what functions change
> variables that aren't copyable?
>
> Noel
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>