lhmouse / intrusive_ptr Goto Github PK

Hello,

could it be that the implementation of dynamic pointer_cast is wrong?

i believe it should be:

 template<typename _U, typename _T>
  intrusive_ptr<_U> my_dynamic_pointer_cast(intrusive_ptr<_T> __r) noexcept {
    const auto __u = dynamic_cast<_U*>(__r.get());
    if(__u){
      __r.release();
    }
    return intrusive_ptr<_U>(__u);
  }

with $dynamic_cast<_U*>$ as in the code i post instead of $dynamic_cast<_U>$ as in the repository

Hello,
i was digging for "intrusive_ptr" implementations in the web and i found very promising your library.
What is the memory cost of each of your intrusive ptrs?
Your implementation gives the same thread safety guarantees as smart_ptrs, right?

On my side, i would be interested in using intrusive_ptrs instead of smart_ptr to reduce memory occupation of my program (as well as ideally to improve efficiency). For this reason i was looking for a lightweight version, without weak counters (i would use raw pointers instead of weak ones)

what would it take to achieve that?

GCC warns of -Wfree-nonheap-object when stack-allocating objects that derive from intrusive_base. The compiler thinks it's weird that there are potentially calls to "delete" on a stack object. Not sure how this warning could be avoided so I personally recommend to silence it at this point if you're ok with being careful of your allocations.

Right now the spec requires that T is a complete type, I feel like this is a tough requirement since neither shared_ptr nor unique_ptr have this requirement. Is there a way to work around the restrictions? The other pointer types have some specific places where completeness is required and other places where it's not. Maybe some detailed rules could be fleshed out here as well.

First of all, thank you for writing this very neat proposal!

I thought I'd make a suggestion to include unit tests with more code coverage. That way it would be easier to check that everything in the implementation works for a given compiler environment.

Cheers!

Hello,
it's a nice template you created but I have trouble understanding a few things.

a) the implementation basically requires atomic variables. However, there are usecases where one wants intrusive_ptr but not including atomic operations, for example because they pull in extra library dependencies on some embedded architectures or because they make the operation slower (memory barriers) although in the specific design the MT-safety might be not required.

Would it be possible to add an inline variant (controlled by traits or prepr. defines) that work without atomic variables?

b) I don't see the point of intrusive_weak_ptr. Maybe it's just missing documentation?

From my point of view, intrusive_weak_ptr does not make any sense. I mean, the basic idea of normal weak_ptr is to a) avoid ref-counted dependency and there allow the object to be deleted and b) giving the user of weak_ptr means to reliable detect whether object was deleted and atomically create a reliable shared_ptr from it.
I cannot see how your current implementation would satisfy such demands, i.e. the point of __lock is to enforce/guarantee... what exactly?

Get pointer from a intrusive_ptr to another intrusive_ptr like below, the reference count is not right

boost::intrusive_ptr<ProcessData> ptr(new ProcessData(1, "a"));
{
        // get from another intrusive_ptr
        boost::intrusive_ptr<ProcessData> ptrCopy(ptr.get());
}

    explicit constexpr intrusive_ptr(_T * __t) noexcept
            : __x_t(__t)
    {
        if (__x_t->_Impl_intrusive_ptr::_Ref_count_base::__get_ref() > 1)
        __x_t->_Impl_intrusive_ptr::_Ref_count_base::__add_ref();
    }

I __add_ref when old __x_t is not 1. Is this right?