intrusive_ptr and incomplete types
From the header file of intrusive_ptr it seems that it can deal with incomplete types. The constructor and destructor use
Dear all.
I was googling about incomplete types and smart pointers but couldn't find a
definitive statement about intrusive pointers.
the 'intrusive_ptr_add_ref' or 'intrusive_ptr_release'. If these are not
invoked, use of an intrusive_ptr with incomplete types should be ok.
So it seems that below example will compile:
//foo.h:
#include
gast128: ...
From the header file of intrusive_ptr it seems that it can deal with incomplete types. The constructor and destructor use the 'intrusive_ptr_add_ref' or 'intrusive_ptr_release'. If these are not invoked, use of an intrusive_ptr with incomplete types should be ok.
So it seems that below example will compile:
//foo.h: #include
class A;
This doesn't answer your question, but if you add void intrusive_ptr_add_ref( A* ); void intrusive_ptr_release( A* ); you can copy intrusive_ptr<A> instances around freely. This achieves a level of incomplete type support that matches shared_ptr<A>.
Peter Dimov
This doesn't answer your question, but if you add
void intrusive_ptr_add_ref( A* ); void intrusive_ptr_release( A* );
you can copy intrusive_ptr<A> instances around freely. This achieves a level of incomplete type support that matches shared_ptr<A>.
I think this gives some linker error. In our code we often use a refcount base class, e.g: class A : public RefCount { }; for the RefCount class has the functions are defined: void intrusive_ptr_add_ref( RefCount* ); void intrusive_ptr_release( RefCount* ); and there is the problem: a fwd decl. is not enough for the compiler to figure out that a matches the RefCount functions.
participants (2)
-
gast128 -
Peter Dimov