From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-05-03 11:00:24
> > Right, warning free code is a good idea.
> > Nevertheless one should specify Boost include path via -isystem
> > path/to/boost and not via -I path/to/boost if one doesn't want to see
> > the warnings in system libraries with gcc.
> That's a bit like putting black tape over a "check-engine" light.
> My primary question still is:
> What is the disadvantage of adding the virtual destructors?
> The Stroustrup book has a very clear recommendation (below).
> Why not follow this advice? I'm keen to learn the facts.
> Stroustrup 2000
> Section 12.4.2 (page 319 in my edition):
> Many classes require some form of cleanup for an object before it goes
> away. Since the abstract class lval_box cannot know if a derived class
> requires such cleanup, it must assume that it does require some. We
> ensure proper cleanup by defining a virtual destructor
> lval_box::~lval_box() in the base and overriding
> it suitably in derived classes.
> ... We have no way of knowing exactly to which class the object pointed
> to by p belongs, but thanks to lval_box's virtual destructor, proper
> cleanup as (optionally) defined by that class' destructor will be
What's the problem with making the destructor virtual in the first place?
Since the class already has other virtual functions this won't generate any
(significant) additional overhead (the only thing what's added is another
function pointer to the already existing virtual function table, barely
something to worry about).
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk