> -Weffc++ is broken and should just die.
-Weffc++ should be made more useful, and able to be switched on a per-rule
basis.
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.
As you are well aware, GCC is part of the GNU project. It's all about
freedom. We're not suggesting that people always use this flag, merely
that if they are motivated, know some C++, and are willing to look
through results that may contain false positives, they will no doubt
find some useful information. I know I do. I don't use this flag all
the time, but do use it on occasion and find the results interesting.
And you know what? This isn't the only C++ language flag that has these
issues. Look at -Wabi and the inlining warnings for similar issues.
There are no doubt other issues with other warnings: every long term
user of GCC no doubt has some favorite carp about the ridiculousness of
some flag or another. Ditching diagnostics because you don't like them
or they are imperfectly implemented seems like a strange course of
action for a member of the gcc SC to advocate.
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.
> The coding rules they propose,
> and that the flag enforces, are completely incompatible with the STL: you
> cannot write a C++ standard library in a way that doesn't either spew tons
> of -Weffc++ warnings or that bloats out most of the objects by adding an
> unnecessary virtual function table to all kinds of objects that are now a
> single pointer (you're pretty much forced to put a virtual destructor in
> any class that is inherited from). That's two pointers instead of one
> in most iterators and function objects.
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.
I thought this particular complaint got fixed in the last round of -
Weffc++ enhancements, where this only warns if derived classes have
virtual functions. I can't find a reference to it in the mailing list
or in bugzilla.
The simple example below doesn't warn, for instance.
struct base
{
void foo();
};
struct derived: public base
{
void bar();
};
-benjamin
