Re: Warning on C++ catch by value on non primitive types

[Benjamin Kosnik <bkoz at redhat dot com>]

> 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."

Yep.

> 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.

Yep.
 
> 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).

Nyet.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14172

> 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.

Agreed. Doing the pragma system header thing was a sad day for me. 

For major releases, I try to run with highest warning flags on both GNU
and EDG compilers, and also bring out the tweaky flags like -Weffc++.
IMHO this kind of effort is only really worthwhile on rare occasions,
and is overkill for day-to-day development.
 
> > 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.

Agreed. However, we can fix the implementation of some of these rules
to make them more sane. If we can, we should, and we should definitely
encourage people to work on this stuff instead of shutting them down
with "kill all warnings" talk.

> > 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.

Thanks to Giovanni for doing the heavy lifting. All I did was complain
in the right place, with enough detail that other people could
understand my complaints.
 
> > 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.

That would be nice. Make sure you put them in bugzilla with -Weffc++ in the keyword.

I seem to dimly recall that one of the remaining issues with bogus
warnings is with the current std::allocator design. That might be a
good first place to start with this examples.

It does seem like the highest-priority item for going forward is
splitting -Weffc++ into smaller, more granular units so that it is
possible for people to use just the useful warnings, and not get what
they feel is noise. As Paolo has pointed out, there is already a
feature request for this very thing: c+ +/16166.

best,
benjamin