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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-03 18:48:02

"Justin M. Lewis" wrote:
> 
> ----- Original Message -----
> From: "Noel Yap" <Noel.Yap_at_[hidden]>
> To: "Boost mailing list" <boost_at_[hidden]>
> Sent: Saturday, May 03, 2003 4:13 PM
> Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance
> 
> > Noel Yap wrote:
> > >   std::auto_ptr< T > t( new T() );
> > >   f( boost::dumb_ptr< T >( t.get() ); // clearly an in/out parameter
> >
> > Or if you don't want to dynamically allocate t:
> >
> >   T t;
> >   f( boost::dumb_ptr< T >( &t ) ); // clearly an in/out parameter
> >
> >   static T t;
> >   f( boost::dumb_ptr< T >( &t ) ); // clearly an in/out parameter
> >
> >   boost::dumb_ptr< T > t = f(); // must be an out parameter whose memory
> > is managed by f()
> >
> >   T t = *f().get(); // must be an out parameter whose memory is managed
> > by f()
> >
> >   T &t = *f(); // must be an out parameter whose memory is managed by
> > f()
> >
> 
> I'm going to have to disagree with those being clearly in_out params.  What
> if the function just takes a pointer?  

If you wrote the function, why did you write it taking in a pointer if
the intent is not an in/out parameter?

>While we do tend to avoid using
> pointers these days, it's not possible to avoid them entirely, and there is
> a lot of code where pointers are being passed around.

In this situation, how is c_out and c_in_out going to help where
boost::dumb_ptr<> will not?

>  So, how do you
> differentiate the case where it's just a pointer being passed, and it's an
> in_out param?

I think you're saying, "I don't want to write functions taking in
pointers even for in/out parameters since there's such a large code base
taking in pointers for in parameters."  If so, for new functions what
about using:

  void f( boost::dumb_ptr< T > t ); // this is an in/out parameter

>  And, there's still the issue of, we LIKE to avoid using
> pointers whenever possible, which you're not doing, you're requiring the use
> of pointers in a case where they're easily avoidable.

Can you explain or elaborate what you mean by "using pointers", please?

Thanks,
Noel