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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-03 19:37:21

"Justin M. Lewis" wrote:
> > 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.

Then why not one of:

  void f( std::auto_ptr< T > t_ ); // passes ownership of pointer to f
  void f( boost::dumb_ptr< T const > t_ ); // caller keeps ownership of
t_

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

The point is that the function cannot operate on t_ so, therefore, t_ is
an in parameter.

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

Huh?

  void f( T const& t_ );
  T* t = new T();
  f( *t );

> you're not referencing and dereferencing.

Like I said before, references are implicitly dereferenced pointers.

>  For example, you don't
> see people testing like this
> 
> void func(T &t)
> {
>     assert(&t != NULL);
> }

I haven't tried it so I don't know if it's possible, but it may be
possible to have a CanBeNull policy on the boost::dumb_ptr<>.

Also, what if you /want/ them to be able to pass in NULL.

Also, isn't the above something you don't want to do since it's not
obvious from the call site whether it's an in parameter, an out
parameter, or an in/out parameter?

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

OK.  I think I see:
- you want to guarantee that the objects passed into the function aren't
null so you're stuck with using references.
- sticking with references only doesn't allow you to differentiate among
in parameters and in/out parameters at the call site.
- out parameters should be returned either by value or by (smart or raw)
pointer.  The function writer should be able to guarantee a non-NULL
return value if it's necessary so the NULL argument doesn't hold here.

Given all of the above, I think you really want to champion c_in and
c_in_out rather than c_out and c_in_out.  What do you think?

Noel