On Thu, 2006-10-26 at 15:29 +0200, Murray Cumming wrote:
> On Thu, 2006-10-26 at 08:58 -0400, Paul Davis wrote:
> > why is this destructor not virtual by default? i thought it was widely
> > accepted good practice that if the class is ever intended to be
> > inheritable, its destructor should be virtual?
>
> Not necessarily. The destructor should be virual if it is intended to be
> used polymorphically.
>
> But yes, this would be useful to me sometimes too. I believe the choice
> was made once for performance.
now this is silly. do you realize that every time you do this:
someSignal.connect (mem_fun (someObject, &SomeObject::method))
that the temporary slot (the one passed to the connect() method) creates
its own trackable, adds a destroy notification callback to the
trackable's callback list, then removes that callback and then destroys
its? this is for every single connect, every time. the cost of this
extra work (including heap allocation of an std::list) versus a virtual
function call when destroying a trackable makes this concern seem
misplaced to me. avoiding the temporary slot from doing all this stuff
would be much more productive in terms of cycles not wasted.
> And you might actually be better off with your virtual inheritance
> elsewhere. Obviously it works for gtkmm, which multiply-inherits
> sigc::trackable. Virtual inheritance is a very odd thing and doesn't act
> exactly as you might expect.
no kidding. 5 days of valgrinding and gdb-ing and reading MB's of
debugging output finally convinced me that VI was the issue. i used VI
to avoid having to constantly specifiy which trackable of the multiple
trackables would otherwise be present i meant, which was apparently what
VI was intended for. instead, it led to gcc completely screwing up the
class layout and consistently messing up object destruction. i've heard
of at least one other story that matches this experience with VI.
--p
_______________________________________________
libsigc-list mailing list
libsigc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/libsigc-list
