From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-03 18:49:02
----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, May 03, 2003 4:37 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance
> "Justin M. Lewis" wrote:
> > > > 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
> > you can't delete a pointer that's taken from unallocated data.
> I had a few suggestions.
> You're right that std::auto_ptr<> isn't a one-size-fits all strategy.
> BTW, I consider all memory to be allocated -- the differences are where
> and how its allocated.
> If std::auto_ptr<> isn't usable in your situation, boost::dumb_ptr<>
> should be.
> > > Since dumb_ptr is just a wrapper around pointers, you can still avoid
> > > using pointers, unless you consider references not to be pointers.
I consider references not to be pointers. I thought that was the point of
references, something that has the benefits of a pointer, without as much
danger as a pointer, that doesn't promote pointer useage.
> I didn't get a response from this comment.
> > > 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
> Neither from this.
Well, out(t) doesn't return a T, it returns a c_out<T>, so it'd be pretty
c_out<T> whatever = out(t);
same with in_out.
> 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