One last time: annoying warning

[Christian Bauer]

Hi!

(Ah, this is great. I haven't had a good flame war for years! :-)

On Mon, Sep 23, 2002 at 08:26:46PM +0200, Roberto Bagnara wrote:
> Christian Bauer wrote:
> > 5) Mutilates perfectly valid code in a feeble attempt to keep some nitpicking
> >    compiler's trap shut.
> 
> "Mutilates"?!
> Putting the argument name within comments "mutilates"?

Changing code for the *sole* purpose of getting rid of a compiler warning
(a warning, remind you; not an error, not a compiler bug, but a *warning*.
Warnings mean nothing. They are produced by a program that doesn't even try
to 'understand' the code. Yes, warnings are useful in 99% of all cases. This
is one example of where they aren't.) isn't my idea of elegant software
development.

> > 6) Doesn't make the code any more transparent. Rather the opposite.
> 
> It makes clear that the argument is _intentionally_ unused.

To whom? To your compiler, perhaps (because someone programmed it to behave
that way). Not to me.

> Pretty obvious in the specific case, but, more generally, not using function
> arguments may happen (and does happen) also by mistake.

Yes, but...

> > Unused parameters are to be expected when overloading functions.
> 
> So what?

So a C++ compiler should know not to complain about that.

> > What is it 'warning' us
> > about, anyway? That the parameter is dispensable and can be removed?
> 
> No: that the parameter is not being used in the function body.

D'oh...

> This catches a significant number of mistakes.

*Potential* mistakes. There is definitely no mistake here.

I still fail to see how this warning is supposed to be useful _in this
specific case_. We are not dealing with a 200+ line function here where
one of the parameters might accidentally have been confused with a similarly
named local variable. This function's body is empty. Any intelligent being
looking at the code can immediately tell that "call_parent" is unused, because
the function, well, doesn't do anything at all. There is absolutely no need
to provide any more information about the unusedness of that parameter.

> Many people use g++ and compile with -Wall and they agree that it is a
> nice thing to be warned about that cases.

I also compile my stuff with -Wall every now and then, but then I sort the
messages produced into three categories:
 1) "Oops. That really is a bug. Thank <insert your deity here> for
    these warnings!"
 2) "Not a bug, but gcc has a point here. Changing the code might make it
    more readable/transparent/portable."
 3) "Bogus warning. Stupid compiler. No cookie. That's why I don't have -Wall
    in the makefile."

Your matter falls into category 3, I'm afraid...

> > There's absolutely *nothing* whatsoever wrong with that line of code.
> 
> Strictly speaking, the line is not wrong but only significantly less useful
> than it could be. It only serves well the portion of your user base not using
> g++ or its extra-warnings options.  It does not serve well others.

Are we on the same page here? I define the usefulness of code by the results
it produces, or by the potential for useful results it may have in the future.
Not by how much output the build process spews out in the case that someone,
somewhere activates _optional_ gizmos on his or her tools.

> > Your 'fix' only serves to outsmart your compiler's warning heuristics.
> 
> It is not a heuristics in the usual sense: unused arguments are always flagged
> when these warnings are enabled.  And this is so by design.  The same
> functionality is available in other C++ compilers.  Guess why.

Because a compiler is a mindless automaton that translates an algorithm into
a different representation? Because a compiler can't (and shouldn't) know
why that algorithm was written down in the exact way it was in the source
file? Because compiler writers are well aware of that fact and have added
an option to suppress these warnings?

> > The function
> > still has one unused parameter. Why doesn't the compiler warn about that?
> 
> Because omitting the argument name is the ISO standard compliant way of
> specifying that the argument is _intentionally_ unused.

Yeah, right. It says so in the standard: "If you want your compiler to shut
the frell up about this stuff, we recommend you put your variable names in
comments.". I don't think so.

(Whoa, wait! Hold your fire! That last comment was meant ironically. I know
what you wanted to say. :-)

> While omitting the argument altogether causes an information loss, omitting
> it by commenting it out is perfectly OK.

...except that it obfuscates the source.

> Instead you are choosing to disrespect users and contributors of GiNaC (and
> the GCC authors as an extra bonus) by imposing your religious arguments upon
> them.

And you are imposing your compiler's imbecility upon us...

Do I tell you how you have to indent _your_ code just because it happens to
be misformatted in the editor _I_ am using? No, I don't. You'd probably say
"Your editor sucks, dude. Use another one, or at least configure it
properly.". And you'd be right.

(And how exactly did I disrespect the GCC authors?)

> This is a serious mistake for anyone and for a library provider is even
> worse.

I'm thankful for any help offered, but I choose to reject patches that seem
pointless to me. I acknowledge that your intentions in proposing this patch
are good, I read it, I gave it some thought, but I've come to the conclusion
that it's a kludge that I'd rather not have in our code. My suggestion still
is to suppress the compiler warnings if they annoy you, or to find a more
appropriate way to deal with them.

> Anyway, starting from now, the PURRS project will reduce its dependence on
> GiNaC as much as possible.

Yeah, go play in your own sandbox! And, I tell you what: We will reduce our
use of PURRS here to zero! Now, how does that feel? (Wait, come to think of
it, we never used PURRS in the first place... What is this 'PURRS', anyway?).

;-)

> At the same time we will create a parallel CVS repository for GiNaC + our
> improvements (you know, those idiotic things we like and you despise).

Isn't that precisely one of the things CVS was designed for?

To summarize:
 - The code in question is 100% valid
 - I also don't think there's any risk of it being misinterpreted
 - Compiler warnings are nothing more than hints, not divine revelations;
   they are therefore to be
    a) subjected to a critical examination
    b) taken with a grain of salt
 - In this case, the warning is pointless
 - Problems should preferrably be fixed at their place of origin
 - In this case, the problem lies with the compiler, not with the code
 - 'Fixing' the compiler is trivial: it has an option to not complain about
   this (which is actually the default setting, but that's only marginally
   relevant here)
 - Therefore, the solution is to change the compiler options. Case closed.

That's all, folks.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/