Re: [boost] [smart_ptr] Some questions

From: Daniel Frey (d.frey_at_[hidden])
Date: 2008-04-09 11:13:00

On Wed, 2008-04-09 at 17:07 +0300, Peter Dimov wrote:
> Daniel Frey wrote:
> > is done the the ctor body. There is even a comment which suggests that
> > there is a problem with doing it before pn, it would not be "safe".
> > What exactly does this mean? px is just a plain pointer, so AFAICS it

> No, copying a deleted pointer is undefined behavior.

Ah, thanks. I just learned something new. :)

> > 2) in detail/shared_count.hpp, operator= for shared_count has an
> > optimization for tmp==pi_. At least I think that it's just an
> > optimization and it would work without the check. OTOH, operator= for
> > weak_count does not check for tmp==pi_. Why? Is there any deeper
> > reason that these two code fragements differ?
> 
> It's a performance optimization. There's no deep reason for the difference.

Maybe it's worth to do the same optimization in weak_ptr::operator=
then?

> > 3) I asked about this point before, but got no real answer: There is
> > no throw specification in shared_from_this()'s documentation. AFAICS,
> > shared_from_this() (if used correctly) can not throw. But will this be
> > guaranteed?
> 
> I'm not sure. It's not guaranteed by TR1 or the draft standard, and I 
> haven't considered the issue in detail to be confident that this is a 
> defect.

I have use cases which would be a lot easier to implement if
shared_from_this() never throws. And - at least with the "old"
implementation - I don't see any reason why this guarantee should not
hold. Of course it's not a defect, but to me it seems desirable.

Since you are also currently working on enable_shared_from_this (which
increases the overhead): Would it make sense if I develop a patch based
on the old version which tries to use detail::weak_count instead of
weak_ptr to create an even lighter, classic enable_shared_from_this? At
least to me the overhead of deriving from enable_shared_from_this is
important...

Regards, Daniel