Re: [boost] [smart_ptr] enable_shared_from_this_light

From: Daniel Frey (d.frey_at_[hidden])
Date: 2008-04-11 19:47:38

On Sat, 2008-04-12 at 01:10 +0300, Peter Dimov wrote:
> Daniel Frey:
> 
> > I attached a complete implementation of enable_shared_from_this_light
> > which has an overhead of a single plain pointer. [...]
> 
> I agree that providing the ability to build this lightweight helper may be 
> valuable to some. But I'm not sure that we should provide several esft 
> classes in Boost (except possibly as examples). This of course raises the 
> question of which esft base (of the three candidates we have) should be 
> provided.

I think that we should first find out which generally useful helper
functions shared_ptr/weak_ptr should have and how we can improve the
framework. It seems to me that access to the shared_count/weak_count
members might be useful, as well as the new ctor(s) (see below).

> > The thing to note is that I added two more things to
> > shared_ptr: _internal_shared_count() and a ctor which takes a
> > detail::weak_count and the raw pointer.
> 
> I'd change the first argument of the new constructor to 
> detail::shared_count.

Wouldn't that lead to an additional reference counter
increment/decrement cycle? Maybe we should add a ctor which takes a
shared_count in addition to the one that takes a weak_count. The ctor
which takes the shared_count might then be used to replace the ctor with
the ignore_enable_shared_from_this_tag?

> I don't like your preferred spelling of the function. It doesn't reflect its 
> semantics in my opinion. In shared_ptr<T> p( new T ), the T object is not an 
> observer, but it does accept p as its owner.

To me "accept_owner" communicates that the callee has to make some kind
of decision of whether or not it accepts the ownership, which I find
misleading. My point of view is that T just observes when a shared_ptr
takes ownership and is notified as soon as it happened. But then, since
I'm not a native English speaker, that doesn't mean much :)

Regards, Daniel