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

Scott wrote: 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...

...

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

Yes, references are important, I am not trying to replace them. 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