RFC: Avoiding #warning (C/C++ preprocessor extension)
Frans Englich
frans.englich at telia.com
Tue Nov 1 16:04:21 GMT 2005
On Tuesday 01 November 2005 13:34, Mirko Boehm wrote:
> On Monday 31 October 2005 23:15, Nicolas Goutte wrote:
> > > I would
> > > say that no release tarball should contain -Werror. It may be useful
> > > during development but it would be unnecessarily painful for release.
> >
> > ... so you cannot even have it in development, except if everybody would
> > use the same gcc version.
>
> Why not? It can be used as a standard during development, and removed
> before the release.
>
> On the other hand, I do not see the point. Removing annoying "unused
> parameter" warnings should be a habit, no need to make the compiler barf at
> the first point where it encounters it. What is wrong with letting make
> finish the compile, and then removing all the warnings at once?
If you ask me: absolutely nothing. The problem, as I see it, is that no one do
that final check. Old warnings stays for ages -- "someone else is supposed to
fix that". Thus, in order to have it done at all, one have put it directly in
front of developers such that untidy code can't end up in the repository in
the first place.
Applying the hypothetical "-Werror at development but not release time" would
no doubt make the code more tidy. Apparently, that people would have to fix
warnings "now" instead of "later" is too much work, and not worth the
improvement it in general would mean.
Quoting: "Removing annoying 'unused parameter' warnings should be a habit". I
think a good habit is doing it right now, when it is introduced. I think "I
will do it later"(tm) is a vague habit.
Personally, I've used -Werror & co for some time, and I find it practical. It
makes me think about the code I'm writing right now -- "Why is the algorithm
I just wrote not using this parameter?", "What did I do wrong since the code
path can end without return value?" -- and after I've fixed it, I simply know
the code is pretty and that it's done and won't be forgotten because it
cannot be.
I don't think one want warnings fixed by a big zombie commit months after the
code was written, by someone other than the original author. One wants it
fixed by the original author, and while intimate understanding of the code is
still there. Perhaps the parameter actually should be used, and that a bug is
hiding.
(That's not the same as saying -Werror comes without trouble, as evident in
this thread. Coolo outlined the trouble when doing large refactorings, and
different compiler versions warn on different things, to name a few examples.
But those are other issues.)
Cheers,
Frans
More information about the kde-core-devel
mailing list