Dear all,

I was very enthusiastic about fixing all warnings, but now I’m concerned whether that’s a good idea. The whole notion of compiling at high warning levels is great, some people even compile with warnings treated as errors. Most of the warnings point to a possible problem, which could thus be fixed already at compile time and this is great. The problem I see is that even though the warnings make sense in say over 90% of the cases, there are cases thay don’t. There are no “one size fits all“ solutions. My concern is that once we start ignoring the 10% of the warnings that “do not make sense” to us, we will be likely to miss 90% (speculatively but just to make a point) of the new warnings that appear. Furthermore, once in the habit to ignore a certain kind of warning, it will be much more likely that we would ignore even true positives – warnings that we should have fixed.

I’m mostly having trouble with this:

Protocols/Gnutella/Packets/Testing/../BinaryReader.h:40: warning: base class ‘class Utils::Encodings::BinaryReader’ has a non-virtual destructor
./Utils/Uri.h:148: warning: base class ‘class QSharedData’ has a non-virtual destructor

QSharedData comes from Qt, so we cannot fix it. BinaryReader and its derived classes are not intended to be used and not at all deleted using a pointer to the base class. I feel like it would be a waste to make the class polymorphic just in order to make the compiler happy. On the other side, the warning could help us in situations where the we do have polymorphic types, so it is generally a good idea not to disable the class. I’ve read some mailing list discussions regarding which cases would be excluded from the effect of this warning, but the only “solution” that seems to work is declaring the dtor virtual. Maybe there is some workaround that I’m unaware of? Pragmas to disable warnings would be compiler specific. And we’d rather not use a workaround that does not produce better code. What do you think?

I’ll be posting again tonight regarding the default ctors and initialization lists.

Regards,

Peter