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

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

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

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

Yes, I have been thinking about in only params, as a case where you're
either giving up ownership of the data, or destroying the data, which may be
the most common instance of these types of data.  I just didn't want to
propose anymore out and in_out are already getting quite a bit of discussion
as it is.  And, again, it makes the intent 100% clear, that, hey, after this
call, I shouldn't go on accessing t like I own it.  Basically, in would say,
there are no guarantees about the state of teh param passed to the function.

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

It's still not clear that you didn't just want a pointer passed to the
function.

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

references are safer in that they tend to mean, this data isn't dynamically
allocated, you're not referencing and dereferencing.  For example, you don't
see people testing like this

void func(T &t)
{
    assert(&t != NULL);
}

because there's an assumption that references are really meant to make
passing large data cheap, without having to resort to pointer notation.  I
guess it makes it clear, that, if you're passing me a reference to data, I
have no intention of checking to make sure that reference is pointed to real
data, that's your job as the caller.  Anyway, the less you use pointers
altogether, the better.  The less likely you are to have memory leaks, and
memory faults.

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