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

Subject: Re: [boost] [exception] warning about non-virtual destructor - resolution?
From: Daniel James (dnljms_at_[hidden])
Date: 2012-04-16 09:29:38

On 16 April 2012 10:20, Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:
>
> I don't see what this has to do with abstract classes.
>
> struct A { virtual void foo() {} };
> struct B : A {};
>
> boost::shared_ptr<A> p(new B);
>
> should issue that warning.

If you bother to try that, you'll find that shared_ptr will correctly
call B's destructor, so it shouldn't issue a warning.

It also demonstrates why you can't rely on the warning, since it will
disappear with the slightest of changes.

>> This isn't just about Boost.Exception. I'm not arguing against it
>> making its destructor virtual.
>
> All the warnings being reported are about error_info not having a virtual
> destructor; I don't see anything specific to shared_ptr here.

The warning turns up in shared_ptr_test. I think I mentioned that before.

> First, it's specific to that compiler. What if tomorrow a new compiler
> decides to add that kind of warning too?

You really can't program for future compiler warnings.

>What if it occurs in slightly
> different scenarios?

Explain please.

> Also it's not clear how warnings are suppressed with those mechanisms,
> especially when templates are involved.

They're not clear to you because you never use them.

> See, we have something that seems to depend on include order here. That's
> the worst possible behaviour.

That's the system header pragma, which, as I previously said, is
problematic. I claimed that the warning mechanism introduced in 4.6 is
not fragile. Please stop confusing the two.

> It looks like if I include boost/exception_ptr.hpp first, then all possible
> warning messages (which *are* useful) would be suppressed from the
> boost/shared_ptr.hpp header.

That's a problem in exception, not with the change we're discussing.
It probably should move its warning pragmas to after it includes other
headers.

> I've made codebases of several hundreds of thousands of lines of code
> warning-free on a variety of different compilers, yet I cannot say I share
> your experience.

Well done, that's great, but different development techniques are
available. Much of boost is pretty low level, so we often include code
that would be problematic in higher level development. shared_ptr
deals with deleting objects so that we don't have to.

We do need to put thought into disabling warnings, and not just do it
everywhere. But a dogmatic insistence on the correctness of all
warnings is almost as bad as dismissing them out of hand.