Re: [boost] [smart_ptr] Proposal to extract intrusive_ref_counter from Boost.Log

Subject: Re: [boost] [smart_ptr] Proposal to extract intrusive_ref_counter from Boost.Log
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-09-01 16:04:15

On Sunday 01 September 2013 21:13:08 Domagoj Saric wrote:
> On 31.8.2013. 21:55, Andrey Semashev wrote:
> > On Friday 30 August 2013 14:55:07 Peter Dimov wrote:
> >> Andrey Semashev wrote:
> >>> On Friday 30 August 2013 10:52:35 Peter Dimov wrote:
> >>> So I take it you don't mind me moving this component to Boost.SmartPtr?
> >> 
> >> I don't mind, but it needs a test or two, a documentation page, and the
> >> intrusive_ptr documentation probably ought to be updated to reference it.
> > 
> > Done.
> > 
> > https://svn.boost.org/trac/boost/changeset/85535
> 
> Given that one of the main 'points' of intrusive_ptr is efficiency,
> forcing a virtual destructor is IMO completely misguided. Policies that
> would (also) allow CRTP+protected-destructor and custom deleters would
> make a more complete product.

CRTP version might be a good addition. Care to submit?

> The polymorphic version should also mark the destructor as nothrow,
> otherwise every function that deals with such an intrusive_ptr in a non
> trivial way (i.e. implicitly calls intrusive_ptr_release(const
> basic_intrusive_ref_counter< CounterPolicyT >*) is a possibly throwing
> function for the compiler...

Destructors are implicitly noexcept in C++11.

> No offence but if you use such an approach even with the low level
> components no wonder Boost.Log is the most bloated Boost library...

That was a bit harsh, you know. The base class is used in Boost.Log where 
there are virtual functions and destructor anyway. If you have particular 
complaints and suggestions about Boost.Log I'd be happy to discuss them in a 
separate topic.