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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-03 16:28:56

"Justin M. Lewis" wrote:
> And, again, I HAVE been using these classes.  That's why I brought them
> here.  I had a problem with functions not being clear, I found a solution,
> that's enforceable, in that people using the libraries I write have to
> adhere to it, I know other people like the idea after having discussions
> with them, so I thought I'd see about giving it to boost and having it out
> there where it's easily accessible to a large number of people.

This thread /has/ gone around in circles.

IMHO, I like the idea of code clarity.  OTOH, I think there are other
solutions to the problem.  Please allow me to elaborate the three types
of parameters and conventions (some already existing).

In parameters: use a const reference or std::auto_ptr<>.  For example:
  void f( T const& t_ );
  T t;
  f( t );

  void f( std::auto_ptr< T > t_ );
  std::auto_ptr< T > t( new T() );
  f( t );

Out parameters: use return values or std::auto_ptr<>.  For example:
  T f();
  T t = f(); // may have problem with troublesome copy constructors

  std::auto_ptr< T > f();
  std::auto_ptr< T > t = f(); // no problem with troublesome copy
constructors

In/Out parameters: use pointers or smart pointers.  For example:
  void f( T* t_ );
  T t;
  f( &t );

  void f( boost::dumb_ptr< T > t_ ); // a pointer type that doesn't
transfer ownership
  std::auto_ptr< T > t( new T() );
  f( boost::dumb_ptr< T >( t.get() );

I think looking solely at the client code, it should be obvious to any
maintainer what's going on.  Also, the only convention above that's not
already in use is the one with dumb_ptr<>.  What do you think?

Noel