On 19/06/07, Alex Burton <alexibu@mac.com> 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.