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: Domagoj Saric (dsaritz_at_[hidden])
Date: 2013-09-01 15:13:08

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. IMO there is no need for a class that 
applies shared_ptr's "I don't care what it costs" design to intrusive_ptr.
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...
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...

-- 
"What Huxley teaches is that in the age of advanced technology, 
spiritual devastation is more likely to come from an enemy with a 
smiling face than from one whose countenance exudes suspicion and hate."
Neil Postman