Re: shared_ptr and real world (explicitly loaded DLLs)
Vyacheslav Lanovets <xentrax@gmail.com> wrote:
Classes with virtual functions and inline constructors can not be used
across different modules (DLLs) if these modules are unloaded during
execution of the program. The reason is that vtable created in inline
constructor can have pointers into address space of such module [MS VC+
+].
In our applications I fix this problem by moving constructor
definitions out of class body into cpp files. Template classes with
virtual functions are reorganized in such a way that any construction
code is linked into modules that are constantly present in memory.
But I want to complain that boost::shared_ptr<> has tricky internals
to provide suport for user-defined delete policies. And these tricks
are based on virtual calls what just crashes our application.
I'd like you to think: do we really need these cool features of
shared_ptr<> or we need simple bullet-proof _standard_ ref-counted
smart pointer?
First some simple facts:
1) DLL's are not part of the C++ standard.
2) shared_ptr [boost/or from tr1] is not an everything fits me smnart
pointer.
Noe if its the virtuals in SHARED_PTR then can templated classes be
used that do not do virtuals, such as
counter is just a class to easily add a reference count to another
class the functionality could be provided in the base class of the
hierachy as long as the functions added are public and non-virtual.
template <class Derived>
class counter
{
long count_;
public:
counter():count_(1){}
void incr_ref() {++count_;}
void decr_ref() {if(--count_) delete static_cast<Derived *>(this);
};
// foo_base is your base class of a hierarchy
class foo_base:public counter<foo_base>
{
// counter is not oop inheritance!!
// it is used not to modify existing source_code too much
// don't delete via counter<foo_base> *.
...
};
now if we provide overloads for
intrusive_ptr_add_ref(foo_base *p) { p->incr_ref();}
intrusive_ptr_release(foo_base *p) {p->decr_ref();}
does passing an intrusive_ptr around cause any problems if
intrusive_ptr has no virtual functions. It is clean of most boostisms
and does little beyond forwarding operations to the ptr contained
in intrusive_ptr and doing the reference arithmetic, assosicated with
copying and assignment destruction, of reference counted ptrs. It
appears as a solution with existing code [even if not in the standard
itself].
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]