Re: [boost] On ownership policies and boost::raw_ptr

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-26 15:19:33

----- Original Message -----
From: "Greg Colvin" <greg_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, June 26, 2002 3:43 PM
Subject: Re: [boost] On ownership policies and boost::raw_ptr

> At 11:00 AM 06/26/2002, you wrote:
>
> >From: "Greg Colvin" <greg_at_[hidden]>
> >
> >> >I think 'c_ptr' would be a very good choice.
> >>
> >> And I still like &*p better than p.get() or mumble_ptr(p).
> >
> >Causes undefined behavior if p is a null pointer, though. :(
>
> Doesn't seem like it should have to, but no such luck.
>
> Of course lots of code using pointers expects never to
> encounter a null pointer anyway, and I'd expect to see
> code that tests for null-ness to use p directly before
> the conversion to a raw pointer.  But I don't know what
> the use cases are for mumble_ptr.
>
I use mumble_ptr() a lot precisely to check if a 'pointer' is null, so I
wouldn't be able to trade it for &*p.
That is, I write this all the time:

if ( get_pointer(p) )
   foo(*p);

The reason is that I use all kinds of smart and dumb pointers, not just
shared_ptr<>, and they all have their own ways to allow me to test for NULL.
With get_pointer(), I can use a consistent idiom with all of them.

BTW, I like get_pointer() better simply because that's what I been using.

> I've been traveling and am jumping in late, so mabye
> this went by already, but I could see the point in
> defining raw_ptr<T> as a wrapper class for a raw
> pointer which, unlike shared_ptr and all, has a
> conversion to T*.
>
Could be, though if it sole purpose is to be implicitely convertible to T*,
I don't see what could it useful for.

...Well, it could return a proxy as operator*() so that operator& returns
NULL when it's NULL... but that's ugly, isn't it?

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com