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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-03 17:49:42

"Justin M. Lewis" wrote:
> 
> Sure, but if you're willing to type auto_ptr<whatever>(v) all over the
> place, why not make the intent explicit and just do out(v)

I see only a syntactic difference here.  I think there's even a proposal
to allow:

  template< typename T >
  typedef auto_ptr< T > out< T >;

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

> So, why not just go all the way and make it 100% clear?

IMHO, my suggestion (aside from dumb_ptr) /is/ already clear since it's
common (or at least published) practice.  In fact, it shouldn't even be
labeled "my" suggestion.

I think, what you're really complaining about is the use of:

  void f( T& t_ ); // this is an in/out parameter

which will be called like:

  T t;
  f( t ); // is this an in parameter or an in/out parameter

so you want to be able to write your functions such that the caller must
use some other syntax for in/out and out parameters:

  T t;
  f( &t ); // must be an in/out parameter

  boost::dumb_ptr< T > t( new T() );
  f( t ); // must be an in/out parameter from its definition

  std::auto_ptr< T > t( new T() );
  f( boost::dumb_ptr< T >( t.get() ); // clearly an in/out parameter

  T t;
  t = f(); // must be an out parameter

  std::auto_ptr< T > t;
  t = f(); // must be an out parameter

The above introduces one new class, dumb_ptr, and uses already existing
practices.  The out and in_out solution introduces two new classes and
uses no existing practices.  Which would you think has an easier
learning curve given typical C++ knowledge and/or experience?

Noel