Overhead of counter and deleter is exactly the same for both shared_ptr and intrusive_ptr - one per object (the fact that intrusive_ptr doesn't support Deleter at the moment is beside the point IMO - it should). Slight difference is that former is require additional new call.
The only "real" advantage of intrusive_ptr is the size of it's instances
Gennadiy
Overhead of counter and deleter not the same because of heap allocation overhead. On VS2005 new is roughly malloc, and malloc is roughly HeapAlloc. HeapAlloc allocation overhead is like extra 16 bytes per allocation plust rounding up to 16 bytes. I'm not optimizing prematurely, allocations were spotted by profiler. For shared_ptr, polymorhic deleter adds alomst no overhaed, because reference counter is allocated as extra block anyway, so polymorhic deleter is sugar for free. For unique_ptr nonpolymorhic deleter is used, because no extra block is allocated, so it would be too expensive to have extra block dedicated to polymothic deleter. For intrusive_ptr polymorhic deleter is too expensive too, and nonpolymorhic can easily be added by intrusive_ptr_add_ref implementetion. Also, member operator delete can be used to control deletion. Of course it cannot be used for PODs, or classes that cannot be changed, but when you can inherit from intrusive_pointee_base, you can also add new/delete operators.