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

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
destruction,
> > 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
obvious

c_out<T> whatever = out(t);
same with in_out.

> Noel
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>