I wrote:
> > -Weffc++ is broken and should just die.
On Thu, Oct 13, 2005 at 02:31:07PM -0500, Benjamin Kosnik wrote:
> If you search bugzilla for "Weffc++" you can get an idea of what are
> considered useful improvements. I don't consider dated diatribes like
> your previous email especially helpful.
See comment #4 to PR 12854. You state, correctly, that "The remaining
bits that warn with -Weffc++ are either mandated by the standard, or
required for performance/size reasons by ABI implementations."
That is, some aspects of -Weffc++ aren't compatible with the C++ standard;
others require that classes that should not have a virtual function table
add one.
You state later in the log that the flag is now usable on mainline. But
if I understand correctly, this is because of the warning suppression in
system headers, and is true only of code that doesn't use the STL heavily
(in particular, deriving from function objects and the like).
I was never crazy about the idea of treating system headers differently
for the purpose of warnings. I understand why it is done and why it is
necessary, but if the GCC project itself cannot produce warning-free
code for system libraries, it suggests that there is something wrong with
the warning. So it's a tradeoff: we can't fix headers provided by others
(OS headers), so it's right to shut up about them. And certainly for
specialized warnings it's understandable that the system header won't
match. But at least for warnings in -Wall, I think the system headers
should pass, and some of the -Weffc++ warnings could legitimately go in
-Wall.
> The alternatives, which include people writing their own tools or
> purchasing proprietary C++ lint tools to do this for them (which still
> have the problems of the current g++ warnings, if not more) are not
> suggestions I consider wise.
I agree. Something like -Weffc++ could be a very nice idea. The problem
is that the original Effective C++ rules have bugs.
> Perhaps you were burned with older implementations of this flag. While
> still not perfect, a lot of improvements went into this warning for
> 3.4.x.
And thanks for doing them.
> The simple example below doesn't warn, for instance.
>
> struct base
> {
> void foo();
> };
>
> struct derived: public base
> {
> void bar();
> };
Right; the warnings come for certain uses of derived. When I have time,
I'll go back over the issues I've had and try to show some examples.
