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

From: Alex Burton (alexibu_at_[hidden])
Date: 2007-06-19 09:17:08

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