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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-03 23:00:49

"Justin M. Lewis" wrote:
> 
> ----- Original Message -----
> From: "Noel Yap" <Noel.Yap_at_[hidden]>
> To: "Boost mailing list" <boost_at_[hidden]>
> Sent: Saturday, May 03, 2003 5:55 PM
> Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance
> 
> > "Justin M. Lewis" wrote:
> > > > If you wrote the function, why did you write it taking in a pointer if
> > > > the intent is not an in/out parameter?
> > >
> > > Maybe you're in a place where you just had to work with pointers.  It
> > > happens.
> >
> > I still don't understand.  Do you intend to rewrite the function
> > interface?
> 
> Ugh, an example.  You have an object that needs a handle that's not going
> away to some other object, say a list.  So, you have a function
> 
> std::list<int> *l = new std::list<int>;
> CObj &obj = GetObj();
> obj.AttachList(in(l));
> 
> CObj::DoSomething(std::list<int> *l)
> {
>     cout << *(l->begin()) << endl;
> }
> 
> So, you have a function that takes a pointer there, because it expected to
> get a list that was dynamically allocated.

What prevents someone from:

  obj.AttachList( l );

> Or, you could be dealing with pointers because you have an object that needs
> to store a handle to something that might change, or might not be available
> at the time of construction, so again, your member functions, or functions
> designed to work on that handle, would take pointers, because that's what
> you know they're going to be.

Why not use pointer wrappers?

> > Wouldn't this still be dynamically allocated memory:
> >
> >   obj* ptr = new obj();
> >   myfunc( *ptr );
> >
> 
> Sure, that is, but, since you're dereferencing there, you KNOW that ptr had
> BETTER be correctly pointed.  You KNOW that myfunc isn't going to delete
> ptr, or anything of that nature.

I see.  So the difference between dumb_ptr<> and the reference is that
the dumb_ptr<> can still point to NULL whereas the reference can't. 
They are similar in that neither will be deleted by myfunc.  What about
ref<>?

> > > But, like I said, there are cases where you have to allocate data.  So,
> how
> > > do you differentiate calls like
> > >
> > > myfunc1(const obj *ptr)
> > >
> > > from
> > >
> > > myfunc2(obj *ptr) ?
> >
> > By using:
> >   void myfunc1( boost::dumb_ptr< obj const > ptr );
> >   void myfunc2( boost::dumb_ptr< obj > ptr );
> >
> 
> In the case of myfunc2, the use of ptr still isn't given at the point of
> invocation.  Is it out, in_out, or just in?  All you know is it's a pointer
> of some sort.

Are you saying that:

  void myfunc2( c_in_out< T > obj );

will prevent you, at compile time, from passing in a c_in_out that's
used only as an in parameter or only as an out parameter?  If so, then
that is a big difference between c_in_out<> and dumb_ptr<>.  Otherwise,
they are the same:

  void myfunc1( dumb_ptr< T const > ptr ); // in parameter by convention
  void myfunc2( dumb_ptr< T > ptr ); // in/out parameter by convention
  void myfunc1( c_in< T > ref ); // in parameter by convention
  void myfunc2( c_in_out< T > ref ); // in/out parameter by convention

> > IMHO, it does.  Like I said, they are just syntactic differences between
> > the two styles (except for the NULL situation).
> >
> 
> Right, so anywhere you use these pointers you could easily decide to pass a
> NULL.  You don't have any real indication whether or not that data is
> allocated, and safe to keep a handle to, or local, and about to go out of
> scope, in the case where you might be passing it as a handle into an object.
> Basically, pointers should be used as handles that are persistent, not for
> local vars that are going to go out of scope.  Pointers are there so you
> have control over when something is allocated and freed.  I guess the best
> way to put it is:
> Pointers give you no guarantee of their existence, ever.  No guarantee that
> they've been created, no guarantee on how long they'll live.  It might be
> safe to keep a handle, it might not.
> 
> References guarantee you the data exists for at least your function call,
> and it's probably not safe to keep a handle to it after that call.

I think you can replace much of my example dumb_ptr<> code with ref<>
and gain the safety you wish.

Noel