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