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.