[patch]: fix compiler warning in CustShrinkTabPager
The CustShrinkTabPager class generates a gcc warning because it has virtual functions but its destructor is not virtual. This patch adds the virtual destructor and stops the warning. NB: there may be a case for rejecting this patch if we're really concerned about the performance of virtual functions (one extra indirection per call). FLTK deliberately avoids virtual destructors whenever possible for just this reason. I seriously doubt that this patch makes any impact on Dillo, but that's just IMHO. Regards, Jeremy Henty
On Wed, Mar 18, 2009 at 09:03:18PM +0000, Jeremy Henty wrote:
The CustShrinkTabPager class generates a gcc warning because it has virtual functions but its destructor is not virtual. This patch adds the virtual destructor and stops the warning.
NB: there may be a case for rejecting this patch if we're really concerned about the performance of virtual functions (one extra indirection per call). FLTK deliberately avoids virtual destructors whenever possible for just this reason. I seriously doubt that this patch makes any impact on Dillo, but that's just IMHO.
What warning do you get? What version of gcc are you using? I'm using gcc version 4.3.2, which is silent on this. -- Cheers Jorge.-
On Thu, Mar 19, 2009 at 08:20:35AM -0400, Jorge Arellano Cid wrote:
On Wed, Mar 18, 2009 at 09:03:18PM +0000, Jeremy Henty wrote:
The CustShrinkTabPager class generates a gcc warning because it has virtual functions but its destructor is not virtual.
What warning do you get?
uicmd.cc:68: warning: 'class CustShrinkTabPager' has virtual functions but non-virtual destructor
What version of gcc are you using?
4.1.2
I'm using gcc version 4.3.2, which is silent on this.
Yes, a bit of Googling confirms that this warning disappeared. An unusual case of gcc becoming more permissive in later versions! The issue appears to be that your destructor must be virtual if you are ever going to delete an object of a derived class via a pointer to the base type, otherwise your object won't get properly cleaned up. My gcc seems to be assuming that this is going to happen, since the class has virtual functions. It looks as though your gcc is smart enough to see that we don't actually do this. I'm finding mixed opinions as to what is the right behaviour, but if the latest gcc is happy then it's probably best to take no action. Sorry for the noise. (Time to upgrade again, I think.) Regards, Jeremy Henty
participants (2)
-
jcid＠dillo.org -
onepoint＠starurchin.org