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

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-03 22:04:15

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

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.

>
> > > Can you explain or elaborate what you mean by "using pointers",
please?
> > >
> >
> > using pointers, it seems pretty self explanatory to me.
> > myfunc(const obj *ptr);
> >
> > If you're not dealing with something where you know you have allocated
data
> > floating around, you should use a reference.
> >
> > myfunc(const obj &ptr);
>
> 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.

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

> > I mean, if you just put dumb_ptr in place of both, how is it any
different?
>
> Because the type with which dumb_ptr is parameterized is different
> thereby creating different types.
>
> > How can you tell one from the other, without looking up the prototype?
>
> Therefore:
>
>   boost::dumb_ptr< obj > in_out;
>   boost::dumb_ptr< obj const > in;
>
>   myfunc1( in_out ); // compiler error; if you want to pass in/out
> parameters into in slots, there can be a conversion operator
>   myfunc2( in ); // compiler error
>
> > I'm just saying, passing by pointer doesn't explicitly tell you
anything,
> > whereas, c_out and c_in_out do.
>
> 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.

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