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.
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.