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

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-03 18:00:14

----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, May 03, 2003 3:49 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance

> "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 >;

I'm not aware that you can have template typedefs, but, I'll go with this
anyway.
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.

>
> 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.

> > 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

my c_out and c_in_out don't have much of a learning curve, they're pretty
straight forward in their use.  And they're 100% clear as to their intent,
whereas, the auto_ptrs are not.  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.

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