Re: [boost] [smart_ptr] trunk version of enable_shared_from_thisincompatible with TR1

From: Daniel Frey (d.frey_at_[hidden])
Date: 2008-04-29 12:49:04

On Tue, 2008-04-29 at 18:45 +0300, Peter Dimov wrote:
> Daniel Frey:
> > TR1 states that the dtor of enable_shared_from_this is non-virtual, the
> > trunk version violates this.
> 
> Yes. This is the least of our worries though.
> 
> We need to decide on the direction we need to take. The upcoming C++ 
> committee meeting is the last chance for a new feature to go into the 
> working paper, and it may even be too late, depending on the LWG mood.

Indeed.

> I'm not sure yet what the best course of action is, but one reasonable 
> course of action would be to propose sp_accept_owner (with the appropriate 
> changes to enable_shared_from_this). An additional proposal may include the 
> member to free function change, if we choose to pursue it.

Just to clarify: The proposed changes do or do not include the current
extension to allow shared_from_this() to be called during the ctor?

> The current state of enable_shared_from_this is not in accordance with this 
> plan. If we propose sp_accept_owner, I strongly prefer the trunk version of 
> enable_shared_from_this to reflect the proposal, in a plain, unoptimized, 
> "reference", doable in user space, form. Daniel, your optimization work 
> takes us further away from this. Now is not the time to optimize; we need to 
> be sure of the specification we're implementing, and even if we were, it 
> pays off at the beginning to have a plain reference implementation that 
> others can lift off as-is and include in their stdlibs.

OK. Note that I only intended to help. I think the communication might
not have been optimal so far, but your post definitely helps me to
understand what the roadmap should be and what I should concentrate on.
Except you think I can not be of any help... :-/

> To get back to the subject, our current specification of sp_accept_owner 
> requires the virtual destructor, a fact that had remained hidden (at least 
> for me) because we don't have a reference implementation of the std changes 
> we're (hypothetically) about to propose. 

I think that if we adopt the approach of turning enable_shared_from_this
into a non-template class and make shared_from_this a free function,
there would no longer be any need for a virtual dtor. Since I don't know
if shared_from_this-from-ctor should be in, I attached two version to
show why the virtual dtor should not be required. I also tried to use
only public interfaces (including sp_accept_owner). Both versions are
untested, though.

Or is there any other reason why sp_accept_owner requires a virtual
dtor?

Regards, Daniel