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

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

"Justin M. Lewis" wrote:
> >   template< typename T >
> >   typedef auto_ptr< T > out< T >;
> 
> I'm not aware that you can have template typedefs, but, I'll go with this
> anyway.

You can't right now, but like I said, it's being proposed.

> Even if that WERE possible, out<T> would just be an auto_ptr, and if you
> made 2 typedefs to match my 2 classes, you'd have
> 
> template< typename T >
> typedef auto_ptr< T > out< T >;
> 
> template< typename T >
> typedef auto_ptr< T > in_out< T >;
> 
> They'd both be auto_ptrs
> 
> So, now you have the function
> 
> void f(out<T> x, in_out<T> y)
> The compiler won't complain about
> f(in_out<T>(x), auto_ptr<T> y);
> because they're all the same type.

in_out should never be typedef'd to auto_ptr<>.  Please read my previous
email for all suggestions.

> 
> >
> > or something like it.
> >
> > > You solution requires just as much typing, and support from developers,
> but
> > > it lacks the explicitness my proposal gives.
> >
> > OTOH, it uses already accepted, common, and published practices.
> >
> > IOW, what other meaning can you garner from:
> >
> >   std::auto_ptr< T > f(); // looks like an out parameter to me
> >
> > or from
> >
> >   void f( T const& t_ ); // looks like an in parameter to me
> >   void f( std::auto_ptr< T > t_ ); // looks like an in parameter to me
> >
> 
> You're back to chasing declarations, and potentially definitions to see if
> the params can change.

How is that?  From the client side, it will be clear whether the
variable is being passed as in, out, or in/out.

I haven't seen you address the issue of in parameters.  I'm assuming you
want something like:

  f( in( t ) );

If so, why not one of:

  void f( std::auto_ptr< T > t );
  void f( boost::dumb_ptr< T > t); // memory is managed by caller

> my c_out and c_in_out don't have much of a learning curve, they're pretty
> straight forward in their use.

std::auto_ptr<> have zero learning curve for those that know the STL.

>  And they're 100% clear as to their intent,
> whereas, the auto_ptrs are not.

I agree with the first part.  I disagree with the second; anyone who has
used std::auto_ptr will know when it's used as an in parameter and when
it's used as an out parameter.  It cannot be used as an in/out
parameter.

OTOH, there would be a learning curve with boost::dumb_ptr<>, but since
it's usage is almost exactly like std::auto_ptr<> and the boost smart
pointers, I would imagine that the learning curve would be close to zero
as well.

>  And, you're still stuck with using pointers
> in your solution, where c_out and c_in_out don't require the  use of
> allocated data, which is nice, since allocated data isn't always convenient.

The suggested boost::dumb_ptr<> doesn't require dynamically allocated
data.  Maybe you're getting confused since I'm giving several
suggestions for the problems at hand.  Here's a more concise one:

In parameter:

  void f( boost::dumb_ptr< T const > t_ ); // look Ma, no dynamic
allocation required

Out parameter:

  boost::dumb_ptr< T > f(); // again, no dynamic allocation required

In/Out parameter:

  void f( boost::dumb_ptr< T > t );

BTW, I don't see why shy away from pointers.  Is it only raw pointers
you don't like, or also wrapped pointers?  Why?  Why don't you consider
references to be pointers that are implicitly dereferenced (a sort of
built-in pointer wrapper, if you will)?

Noel