From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-03 18:01:13
----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, May 03, 2003 3:57 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance
> "Justin M. Lewis" wrote:
> > auto_ptr isn't a great solution, I'd rather not have to new everything
> > can be changed inside a function.
> If it's to be changed within the function, it's either an out parameter:
> T f();
> std::auto_ptr< T > f();
> boost::dumb_ptr< T > f();
> or an in/out parameter:
> void f( T* t );
> void f( boost::dumb_ptr< T > t_ );
> > How would you handle a class member
> > that's not a pointer?
> I don't understand. Why not take the it's address?
You were suggesting auto_ptr, auto_ptr deletes its contents on destruction,
you can't delete a pointer that's taken from unallocated data.
> > Anyway, the classes I suggested make it explicitly clear what's going
> > out and in_out, with helper functions that you use at the point of
> > invocation to get an object of the desired type, so, at the invocation
> > explicit that param x is out, and param y is in_out. Plus you get to
> > using pointers, which is always nice.
> Since dumb_ptr is just a wrapper around pointers, you can still avoid
> using pointers, unless you consider references not to be pointers.
> Also, what stops people from:
> T t = out( t_ );
> f( t ); // this is an out parameter
> T t = in_out( t_ );
> f( t ); // this is an in/out parameter
> 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