Re: [boost] [exception] warning about non-virtual destructor - resolution?

Subject: Re: [boost] [exception] warning about non-virtual destructor - resolution?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2012-04-16 18:32:06

On Mon, Apr 16, 2012 at 1:51 PM, Andrey Semashev
<andrey.semashev_at_[hidden]>wrote:

> On Monday 16 April 2012 12:12:21 Emil Dotchevski wrote:
> > >
> > > You're really hard pressed to come up with situations where you would
> care
> > > about an extra virtual table entry and an extra indirection while
> > > deleting.
> >
> > The reason to care isn't performance. I tend to take the virtual keyword
> > seriously when I read code: it is an invitation to call the function
> > through a base type pointer. In this case it would be a bug if the
> > destructor is ever called virtually. You'll know your compiler is wrong
> > when it tries to "protect" you from conscious and correct design
> decisions.
>
> IMHO, you are taking it too seriously. If you want to disable the call to
> the
> destructor, you typically declare it private or protected. Whether it is
> virtual or not is another story and irrelevant to the access restriction
> (which is actually what you're trying to impose).

The meaning of virtual is "this function is designed to be called through a
base type pointer". This is simply not true for this code, it would be
misleading and incorrect to use virtual in this case.

> And declaring it virtual
> doesn't make the code uglier. In fact, compared to all the machinery
> required
> to disable the warning for every compiler, it is a cleaner solution.
>

The "machinery" is needed anyway to disable all other warnings, and it is
much cleaner than dealing with each individual warning emitted by the many
compilers Boost is used with.

Besides, if a warning (any warning) escapes the "machinery", this is a bug
that I want to fix. In this particular case, people say they get the
warning but nobody has given me exact code that produces it.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode