Re: [boost] cannot pass objects of non-POD type ‘class boost::detail::shared_count’ through ‘...’; call will abort at runtime

Subject: Re: [boost] cannot pass objects of non-POD type ‘class boost::detail::shared_count’ through ‘...’; call will abort at runtime
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-09-19 07:01:52

Stefan Strasser wrote:
> Am Thursday 17 September 2009 14:58:23 schrieb Peter Dimov:
>> The signature of sp_enable_shared_from_this has changed, it now
>> takes a pointer to a shared_ptr as its first argument. Look at the
>> current shared_ptr constructor:
>>
>>     template<class Y>
>>     explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be
>>     complete {
>>         boost::detail::sp_enable_shared_from_this( this, p, p );
>>     }
>>
>> Relying on implementation details has its maintenance costs. :-)
>
> I wondered before why shared_count is an implementation detail.

Well, in this specific case the implementation detail being relied on is 
sp_enable_shared_from_this, not shared_count. shared_count being pubic and 
documented wouldn't have helped.

> there are obviously use cases besides shared_ptr for this. one of
> those use cases is even endorsed by boost, by offering intrusive_ptr.
> and the implementation of shared_count has performance advantages
> over every portable solution possible, as its implemented compiler-
> and platform-specific for many combinations.
> so, why's shared_count an implementation detail?

Originally, the reason was that we didn't want to overspecify shared_ptr. 
Later on, the reason was that exposing shared_count and its relationship 
with shared_ptr would have allowed people to get around the eventual 
limitations of the shared_ptr interface; since std::shared_ptr has no 
std::shared_count, this would have meant that std::shared_ptr could be left 
suboptimal.

One might argue that these reasons are no longer valid, although I still 
have my doubts. It'd be better for people's code to port cleanly between 
boost::shared_ptr and std::shared_ptr. There is indeed the option of 
documenting shared_count but not its relationship with shared_ptr, but this 
would just invite the obvious follow-up questions.