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

Subject: Re: [boost] [exception] warning about non-virtual destructor - resolution?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-04-16 11:45:32

On 16/04/12 15:29, Daniel James wrote:
> 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.

I didn't know that shared_ptr called the destructor of the type it was 
given in the constructor.
That seems like a bit of a dangerous design.

So the above will work, but not

A* p0 = new B;
boost::shared_ptr<A> p(p0);

I think silencing the warning might be the best solution in this case.

> You really can't program for future compiler warnings.

Compiler warnings output messages that have been engineered by people to 
find potential problems in source code.

If you code in a way that a human wouldn't see a potential problem in 
your code, then a compiler also will not.

>> What if it occurs in slightly
>> different scenarios?
>
> Explain please.

In certain cases, the potential problem of a non-virtual destructor 
generates a warning when the declaration of the destructor is 
encountered. In other cases, the warning gets generated when a call to 
the destructor is made. In yet other cases, only if the call to the 
destructor is made through the delete operator.

Fixing the source of the problem is easier than adding kludges in every 
place the problem could end up being diagnosed.

>> 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.

I've used the MSVC pragma push/pop warning disable thing pretty 
extensively, and I've had quite a few problems with it when templates 
are concerned.

I suppose GCC, while essentially using the same syntax, does it better?

> 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.

Boost isn't particularly low-level. On the contrary, it is very high 
level compared to average C or C++ development.