Boost logo

Boost :

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
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at