On Thursday 26 October 2006 19:34, Murray Cumming wrote:
> On Thu, 2006-10-26 at 12:06 -0400, Paul Davis wrote:
> > just to be clear, what i said about "this is silly" was focusing on
> > the
> > size of trackable and derivatives when runtime performance was so
> > poor
>
> Karl Nelson was quite obsessed with runtime performance (though
> probably more on signal emission than signal connection,
> understandably), and runtime memory use. If you can improve it, for
> some future
> parallel-installable version of libsigc++, and prove that it's an
> improvement, you might try to provide a patch.
IMO, any change which fixes undefined behaviour should be made
regardless of any perceived performance hit.
As you said earlier:
> It's undefined (or quite clearly, a memory leak, I
> think), if you use it polymorphically (because you are likely to
> delete it via the base class.
Whether it's undefined only when i delete using a parent pointer or a
child pointer is irrelevant. Opening the door to undefined behaviour
leads to undefined behaviour. The door shouldn't even be open.
> That's why compilers warn if you have
> virtual methods without a virtual destructor.
Not all do. Recent gcc's do, but several common compilers do not.
> In this case, nobody is very likely to use the sigc::trackable base
> class directly.
i'm not so optimistic about that point. The moment someone does use a
trackable like that, they've got undefined behaviour and probably won't
know why. They know that trackable is *meant* to be subclassed, and
therefor presumably has the required virtual dtor. It's just good, safe
practice to do so.
To quote Scott Meyers, More Effective C++ 3rd Edition, Item 51, page
255-256:
"Interestingly, the size_t value C++ passes to operator delete may be
incorrect if the object being deleted was derived from a base class
lacking a virtual destructor. This is reason enough for making sure
your base classes have virtual destructors, but Item 7 describes a
second, arguably better reason."
In Item 7, page 44, he summarizes:
- Polymorphi base classes should declare virtual destructors. If a class
has any virtual functions, it should have a virtual destructor.
- Classes not designed to be base classes or not designed to be used
polymorphically should not declare virtual destructors.
We could nit-pick on whether trackable meets that last point, but IMO
*any* public subclassing is inherently polymorphism because it allows
an implicit conversion from a derived to a parent pointer type:
struct foo : public trackable { ... };
trackable * t = new foo;
This is already polymorphism, regardless of any function calls. A dtor
is a function call, too, so i will argue that any public subclassing is
automatic polymorphic behaviour.
--
----- stephan s11n net http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
Attachment:
pgp53urtx3BZr.pgp
Description: PGP signature