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