Re: [boost] Request for consideration for my weak_ptr class

From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2007-06-19 23:29:15

On 19/06/07, Alex Burton <alexibu_at_[hidden]> wrote:
> Yes, thats exactly how I was using raw pointers (and keeping my code
> free of the delete keyword).
> However when the code changes from Foo * to scoped_ptr<Foo> or from
> auto_ptr<Foo> to Foo *, it seems much more logical and consistent to
> change from simple_ptr<Foo> to scoped_ptr<Foo> or from auto_ptr<Foo>
> to simple_ptr<Foo>.
> It also requires slightly less key presses in my opinion, as only the
> name of the pointer type has to be changed, where as with raw
> pointers it requires edits  on both sides of the type name.
>
> I suppose my point is now that C++ developers have been so clever to
> have written smart pointers, and that those smart pointers require a
> different form to the raw pointers, then to keep the language looking
> consistent it makes sense to get rid of the raw pointers entirely and
> leave them to become another relic from C that C++ programmers have
> access to but choose not to use.
>
I'd take the opposite viewpoint.  It's absolutely essential that
shared_ptr, for example, have a different syntax than raw pointers.

typedef int *myptr_t;
int *p = new int;
myptr_t p1 = p;
p1 = new int;
delete p1;
p1 = p;
delete p;

Perfectly safe.  Change myptr_t to a shared_ptr<int>, and it doesn't
compile.  This is a good thing, because if it did, you'd delete
something twice.

> Yes it is unprecedented as in usually a smart pointer does something
> smart.
> If smart pointers are pointers that do something smart then it is not
> one.
> If smart pointers are template classes with overloaded -> and *
> operaters then it is one.
>
Do you consider boost::optional a smart pointer?

> The container example is just one, there are many instances where
> taking a simple_ptr from a Foo object, which may change to a
> scoped_ptr<Foo> object, etc make this useful.
>
Can you elaborate them?

For the returning case, I don't see why returning a reference is
insufficient.  For the container iteration case, it seems like
ptr_vector or a dereferencing iterator adapter is a much clearer
method.