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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-03 22:25:55

"Justin M. Lewis" wrote:
> Again, why use pointers where we can use references?  And, again, the intent
> is 100% clear with a c_in parameter, where it's not with a pointer.

Again, I think it is clear with the usage of dumb_ptr<>.

Also, IIRC, there's a boost::ref<> class that can be used the same way
I've been describing dumb_ptr<>.

> > > 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.
> 
> You sure are dereferencing that pointer there.  Not at the call, but inside
> the function you certainly access the data inside that pointer.

I think you might be replying to yourself here (count the number of '>';
my post has two).

> > Like I said before, references are implicitly dereferenced pointers.
> >
> 
> I think Floris responded to this claim a few times.  I'm with him.

Why?  Noone has given an example of why references can't be considered
to be implicitly dereferenced pointers.  OTOH, the following clearly
demonstrates that they are logically equivalent:

  T t;
  T* p = &t;
  T& r = t;

  assert( *p == r );

IOW, whenever r is used, one can just as easily use (*p).

> If you want to be able to pass NULL do something like
> 
> void myfunc(c_in_out<CObj *> x);

What's the difference between the above and:

  void f( dumb_ptr< CObj > x );

> Now you have a function that is actually dealing with pointers, not just
> using them as a subsitute for references.

As for references (IIRC):

  void f( ref< T > t ); // in/out parameter
  void f( ref< T const > t); // in parameter

> I like the safety of references over pointers.  Like I said, in general use,
> when you have references you tend to not do as much data allocation and
> deallocation.

I don't see why this is necessarily so:

  T t;
  f( &t ); // using pointers with no dynamic allocation or deallocation

  static T t;
  f( &t ); // same here

>  You don't need to think about the case where someone passes
> you a bogus pointer, because people tend to be passing non-pointer data.

Then use ref<>.

> So, anyone who IS passing allocated data gets stuck with taking care of
> making sure the data is allocated and pointed properly before passing.  To
> me it says, this function only deals with real data, it doesn't handle cases
> where this data does not exist, so you can avoid all of the assert(ptr !=
> NULL); all teh way down the call chain from there, since, if you were going
> to do it right, every function that takes a pointer as a param would check
> to make sure that ptr is not null, with at least an assert.

Then use ref<>.

> I do really like the idea of a c_in as well.  As it happened though, my
> first use was for an out only param, and originally when I started this, I
> had no concept of out, in_out, and in.  It was originally just called
> retval, after talking with others it was split into c_out and c_in_out,
> then, later after that, after I brought the idea here, someone else asked
> about in params, the type of in params I've been talking about, where the ca
> ller is giving up ownership of the data.  But, yes, ultimately I would want
> to see a c_in in this library.

My point was (before I remembered ref<>) that there's really no need for
c_out -- out parameters can be return values:

  dumb_ptr< T > f();
  ref< T > f();
  T f();

After I recalled ref<>, there's no need for any of c_in<>, c_out<>, or
c_in_out<>.

As for ownership semantics, auto_ptr<> takes care of that.  If you're
thinking you don't want to dynamically allocate memory for auto_ptr<>,
ownership of static or automatic memory isn't yours to pass, anyway.

Noel