Boost logo

Boost :

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
> > be modifying their internal state. And, while you may not use
> > 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
> > 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at