Boost logo

Boost :

From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2005-10-27 00:11:28

At 21:52 2005-10-26, Matt Calabrese wrote:
>On 10/26/05, Victor A. Wagner Jr. <vawjr_at_[hidden]> wrote:
> > perhaps some other paragraph? this doesn't address anything about
> > derived objects.
>Just look 2 paragraphs further:
>5.3.5 paragraph 3
>"In the first alternative (delete object), if the static type of the operand
>is different from its dynamic type, the static type shall be a base class of
>the operand's dynamic type and the static type shall have a virtual
>destructor or the behavior is undefined." ...

indeed, but there is no dynamic type vs static type in the example.

>The paragraph then goes further to talk about arrays.
>As for interest in the STL containers with virtual destructors, I'd
>personally say no.

I didn't suggest them, I'm arguing that for the example given they
aren't necessary

> I've never encountered a situation where it would be
>useful or at least useful and better than other alternatives. Anyway, the
>desire for a virtual destructor could exist with any type. If someone wants
>virtual destructors for STL containers, then what next? multi_array with
>virtual destructors? graphs? Forgive me if that sounds like a slippery slope
>argument, but really I see no logic as to why one would want virtual
>destructors for STL containers yet not any other types. You can use the same
>type of argument for any type you can think of -- "I want to derive from the
>type and then add functionality, but want to delete it via a pointer to the
>base class".

I have never said such. I don't know where you got the idea I had.

> Does this mean that all types should have one version with
>virtual destructors, and one without? Definately not. I just don't see why
>someone would want to make the exception for STL containers.
>-Matt Calabrese
>Unsubscribe & other changes:

Victor A. Wagner Jr.
The five most dangerous words in the English language:
               "There oughta be a law"

Boost list run by bdawes at, gregod at, cpdaniel at, john at