I just did a rebuild after updating to the new layout.
When I did, it came up with 805 warnings.
Eeeek!!!!
Guys, when you have a chance, see if you have -Wall configured and try to get to zero warnings. I know a lot of more verbose ones have come up recently, especially with our changes to C++ and such. So I am being a bit of a complainer here.
:-)
But... on projects I've seen where warnings were kept out, quality came up. So though I expect zero-warnings may not be hit any time soon, keeping that in mind as a goal will help our code be better.
Thanks.
On Sun, Feb 29, 2004 at 06:16:00PM -0800, Jon A. Cruz wrote:
I just did a rebuild after updating to the new layout.
When I did, it came up with 805 warnings.
What warnings are shown will depend on compiler version, and to a lesser extent on what CXXFLAGS and CPPFLAGS are in use.
g++-3.3.3 -g on Gnu/Linux/x86 had zero warnings a couple of days ago; about 6 warnings crept in since then (mostly from Fred's renderer), which are now addressed.
Some earlier versions of g++ don't support -Wno-unused-parameter, so there'll be lots of unused argument warnings. (We should slowly try to address those, but it seemed like a lot of warnings to sort through for only small number of detected real problems.)
Some warnings checks are done only when optimization is enabled, whereas I'd guess that most developers compile without optimization enabled. (With g++-3.3.3 -O2 on Gnu/Linux/x86, I found about 3 such warnings, which I've now addressed.)
There may also be warnings that depend on what #if code regions are enabled (e.g. Windows vs Un*x/Gtk).
What sort of warnings are you seeing? What compiler version?
But... on projects I've seen where warnings were kept out, quality came up. So though I expect zero-warnings may not be hit any time soon, keeping that in mind as a goal will help our code be better.
People may try including -Wunused-parameter in their CXXFLAGS. Cases where the unused argument is definitely not something to be addressed (e.g. glib callbacks where the corresponding g_signal_connect (or whatever) unconditionally passes NULL for the data argument), the argument name can be removed:
sp_seltrans_handle_event(SPKnot *knot, GdkEvent *event, gpointer data)
becomes
sp_seltrans_handle_event(SPKnot *knot, GdkEvent *event, gpointer)
However, if in doubt, leave it for the person who wrote the code to decide (i.e. leave the warning there, or add a fixme comment).
As I say, I'm not sure what the payoff for addressing these warnings is, though certainly there are some places where it looks unintentional that the extra arguments aren't used (i.e. where it looks like they should either be used or pruned).
pjrm.
participants (2)
-
Jon A. Cruz -
Peter Moulder