Re: [boost] [smart_ptr] enable_shared_from_this and multiple inheritance solution

Subject: Re: [boost] [smart_ptr] enable_shared_from_this and multiple inheritance solution
From: Ansel Sermersheim (agserm_at_[hidden])
Date: 2010-11-30 12:05:12

Frank Mori Hess <frank.hess_at_[hidden]> writes:

> On Monday 29 November 2010, Ansel Sermersheim wrote:
>> After mulling this over for some time, I _think_ I have come up with a
>> solution that mitigates all these problems.
>>
>> I have a new patch up, at the same URL. In order to make this
>> mechanism work, I had to add a new constructor to
>> boost::shared_ptr<T>, which I am loath to do. Given that downside the
>> patch appears to work properly. It also adds a free function
>> boost::shared_from<T>(T*) which returns a boost::shared_ptr<T>.
>>
>> The only cast that occurs in this code is a static_cast that downcasts
>> from enable_shared_from_polymorphic<T> to T. I have read the relevant
>> portions of the standard several times and I beleive this is valid,
>> but I would definitely be curious if wiser heads agree with my reading.
>
> If you use a free function only (see enable_shared_from_raw.hpp in trunk), 
> the enabling base class doesn't have to use the CRTP.

That is true. However, part of my goal was to create a drop-in
replacement for enable_shared_from_this which will work even when
multiple classes in the inheritance heirarchy inherit from it. Thus,
shared_from_this() needs to know what type to return.

It certainly would be possible to have another type that inherits from
enable_shared_from_polymorphic_base, which would then allow use of the
free function. Or the free function may not be the most desirable
interface. An earlier version had shared_from as a method, so that one
could only call it as shared_from(this). I haven't really thought
through the pros and cons of free function vs method at this point.

> Why did you need another shared_ptr constructor (sorry, I don't have
> time to actually read the code)?  It's hard to imagine, given the
> presence of the shared_ptr aliasing constructor.

Now why on earth didn't I see that the last time I looked at the
available shared_ptr constructors? That is exactly what was needed.

This removes one of my major dislikes about this approach. I will
respin a new patch later today and clean up this area.

Thank you very much for the critique,

Ansel