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. Ralf
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 called.
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). Regards Hartmut