Scott wrote:

raw_ptr might be a better name, then. It's less than weak, since weak pointers are actually quite intelligent, knowing whether or not they're dangling. At the moment i think simple_ptr is best, raw_ptr would cause confusion when speaking of actual raw pointers and raw_ptrs.

...

It allows my code to be free of the * pointer notation. All pointers look the same, ie shared_ptr<Foo>, scoped_ptr<Foo>, weak_ptr<Foo>

Those smart pointers are all well-behaved, though. raw pointers are not. a raw pointer is only not well behaved in that it may point to an object that may or may not need to be deleted at some time. A (now simple_ptr) shows that the programmer explicitly says that this pointer is only used for observing the pointed to object, and doesn't own or share it.

...

It can be used in many places a reference would be used.

You can't get the address of temporaries, so I don't understand where you'd use it in place of references... Yes, references are important, I am not trying to replace them.

...

In the above code, if vector<Foo> foos was changed to vector< shared_ptr<Foo> > the code will still work perfectly with out change.

I find this really useful because often small structs become polymorphic classes (requiring shared_ptr) as code evolves.

The vector example is the best, but even when returning a pointer to something like this it is good:

if Bar mBar becomes scoped_ptr<Bar> mBar, the accessor still compiles.

For your vector example, have you considered starting with vector<Foo>, then changing to ptr_vector<IFoo> later? I think that'll get you the same effect, but it's much safer. Yes, i am not familiar with ptr_vector, but a quick look at it suggests that it would solve that problem.

That constructor from a reference also looks like it'd be far too easy to mistakenly return a pointer to a local variable. Yes the constructor from a reference would allow some dangerous things, and I wouldn't suggest a constructor like this was added to any of the boost smart pointer classes. The reason I think it may be permissible here is because the simple_ptr is explicitly non owning and therefore you need to make sure that the pointed to object exists just the same as a raw pointer.

I'm not convinced that your method is much superior to returning a reference and, if the member does become a pointer, just adding the * to dereference it in the accessor. I'm not convinced by saving having to type this one * either, but it is the cumulative saving of quite a few changes like this that I find motivating.

Probably not quite following just yet, Don't get this wrong - there isn't much to follow, this class does absolutely nothing functional. But it does Change the syntax of code - unifying pointer syntax in the presence of other smart pointer types Make code more explicit - by removing ambiguous raw pointers Save some work when things change - by doing the conversions for you with implicit constructors, which are not dangerous because the class is explictly a non owning pointer. Allow null pointer dereference check.

Alex