I'm creating wrapped completion handlers using custom memory allocators ([url=http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/asio_handler_allocate.html]boost::asio::asio_handler_allocate[/url] for example)
I want to keep them in a ScopedPointer or ReferenceCountedObjectPt type of container, but there's no way to specify the deletion policy of the underlying object. I'm going to add it to Beast of course. But how would you do it Jules?
Does it go in the [b]ReferenceCountedObject[/b] class itself? Or what?
Or do I just override operator delete for my class?
Then I went through all the JUCE containers and made them go through ContainerDeletePolicy<>::destroy. The only trick part was ReferenceCountedObject::decReferenceCount, since it doesn’t know the underlying type. So I changed it to this:
/** Decreases the object's reference count.
If doDelete is true the object will be deleted when the reference
count drops to zero. The delete is performed using the regular
operator and does NOT go through the ContainerDeletePolicy.
The return value indicates if the reference count dropped to zero,
so callers who know the derived type can use the ContainerDeletePolicy.
*/
inline bool decReferenceCount (bool doDelete = true) noexcept
{
bassert (getReferenceCount() > 0);
if (--refCount == 0)
{
if (doDelete)
delete this;
return true;
}
return false;
}
Then I made ReferenceCountedObjectPtr check the return value and call ContainerDeletePolicy<>::delete when the count drops to zero.
FYI I've added something similar to this now. I thought it was best to use two separate decrement methods to avoid that bool parameter, because this is a very performance-sensitive method, and I don't quite trust the compiler to optimise-away the 'if' statement in all cases.
Jules if you have templated copy construction and copy assignment in RefCountedObjectPtr then do you still need the non-templated copy constructor and copy assignments? Seems to be redundant.