Re: If GC is the solution, then what is the problem?
marius lazer wrote:
With all due respect (and I have plenty), smart pointers do pervade our
over 2 million lines of code but not directly; every instance of a
class that can be dynamically allocated has an associated typedef of
the "right" loki::SmartPtr specialization or raw pointer (class ABC has
a ABC_Ptr too). We don't even need code reviews to catch offenders
since a simple grep does the job.
Is ABC_Ptr declared in the header file for ABC or in a
"forward-declaration" header. Otherwise how do you forwardly declare
your classes or do you not apply that principle to abstract base
classes?
I haven't seen the performance problem introduced by smart pointers
properly used. It is an overhead, it's true, but it's noise in the
global picture. When the use of smart pointers become my performance
problem I'll be in really-really good shape... And yes, signatures are
defined in the design process and whenever appropriate we take
references to ClassPtr to avoid the extra copy.
I'm also not 100% certain of the claimed "efficiency" of using
gc-pointers. Has it been tested in practice and in the test were
smart-pointers being used correctly? I don't know exactly how gcs work
but my impression would be that a pointer is no longer a simple POD as
the garbage collector has to keep track of every pointer in existence
and thus every pointer copy made, so a memcpy on a vector of
gc-pointers might screw up the garbage collector. Perhaps Kanze and
others can enlighten me, or do you just use them without caring how
they work (or just assuming they do).
Now, has anyone in this topic yet mentioned the co-variance problem
with smart-pointers? Let's say I have this model:
class A; // abstract
class B : public A; // also abstract
class AImpl : public A; // concrete
class BImpl : public B; // concrete
Now suppose I have this factory template:
template < typename T >
struct Factory
{
virtual ~Factory() {}
virtual smart_ptr<T> create() = 0;
};
Now suppose I have a factory that creates BImpls. Should I derive it
from Factory<A> or Factory<B> ? Now even without smart pointers you
have the problem that Factory<A> and Factory<B> are unrelated (not
co-variant) but you could derive from both classes except that the
return types are now also not co-variant. Note that if you get create()
to return raw pointers you can indeed derive from both classes
(although it's clumsy).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]