Hi Markus,

The compiler has always right. You should never ignore a warning. ;)

That’s exactly my problem! I believe the compiler is right most of the time but unfortunately not all the time! I was especially concerned about ignoring warnings (and the practical implications of ignoring them) and that is why I started the discussion…

Hi Petr,

* Use a public and virtual dtor - this is mostly what you want if you want to allow users to call a delete operator on a derived-class object via a base-class pointer.
* Use a protected and non-virtual dtor - this is used when you don’t want to allow users to call a delete operator on a derived-class object via a base-class pointer. An example could be policy classes (see Modern C++ Design by A. Alexandrescu (book) for more details).

I found this discussion on the gcc mailing list about “our” warning:
http://gcc.gnu.org/ml/gcc/2000-08/msg00215.html
http://gcc.gnu.org/ml/gcc/2000-08/msg00217.html
which suggest two solutions:
- deriving privately (class MyClass : private Base)
- declaring the dtor private in the base class
In both cases delete (Base *) object; won’t compile. Unfortunately it seems that doing either does not get the warning away. :-)

How do you filter your output? I initially used:

grep '^\.' warnings.log > warnings.filtered.log

to only get the errors from files located in . or below but then I found out not all calitko paths are prepended with ./ so I now use:

grep '^[^/]' warnings.log > warnings.filtered.log

to ignore all Qt warnings.

Regards,

Peter