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();
> 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
> > > But, like I said, there are cases where you have to allocate data. So,
> > > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk