[PURRS-devel] [Fwd: Re: One last time: annoying warning]

Roberto Bagnara bagnara at cs.unipr.it
Mon Sep 23 19:28:02 CEST 2002


-------- Original Message --------
Subject: Re: One last time: annoying warning
Date: Mon, 23 Sep 2002 17:26:27 +0200
From: Christian Bauer <cbauer at zino.physik.uni-mainz.de>
Reply-To: ginac-devel at zino.physik.uni-mainz.de
To: ginac-devel at zino.physik.uni-mainz.de
References: <3D8E0293.8040109 at cs.unipr.it>

Hi!

On Sun, Sep 22, 2002 at 07:49:07PM +0200, Roberto Bagnara wrote:
 > I was composing my fourth message about the the unused parameter
 > in line 84 in basic.h (GiNaC 1.0.11)

And I'm now composing my third answer to that...

 > and about the trivial and 100% safe patch I have proposed to fix it.

Short answer: There is nothing to 'fix' here.
Long answer: See below.

 > Having discovered that I was not completely ignored during all this time,
 > I had a chance to erase a message you would not have liked.

/me dons the asbestos suit

 > I would now like to discuss the issue on purely technical grounds.

So do I.

 > The point is that we need to replace  the following line (84) of basic.h
 >          virtual void destroy(bool call_parent) { }
 > with the following
 >          virtual void destroy(bool /* call_parent */) { }
 >
 > We cannot follow the advice of Christian Bauer (*) to tell the
 > compiler not to warn about unused parameters for the simple
 > reason that we find these warnings very useful in our
 > development work.

Then write a script that filters out warnings coming from ginac/basic.h...

 > In contrast, I believe the patch I am repeatedly proposing:
 >
 > 1) complies with the C++ standard;
 > 2) does not cause problems with any the versions of all the C++
 >     compilers we know of;
 > 3) preserves the information about what the bool parameter is;
 > 4) is good both for users that run with warnings on and for those
 >     switching them off.

5) Mutilates perfectly valid code in a feeble attempt to keep some nitpicking
    compiler's trap shut.
6) Doesn't make the code any more transparent. Rather the opposite.

Unused parameters are to be expected when overloading functions. A compiler
that issues a warning about this needs to be gagged. What is it 'warning' us
about, anyway? That the parameter is dispensable and can be removed? That
would make some sense if this was pure C code. But here, the parameter is
needed. The compiler is just too stupid/ignorant to see that.

There's absolutely *nothing* whatsoever wrong with that line of code. Your
'fix' only serves to outsmart your compiler's warning heuristics. The function
still has one unused parameter. Why doesn't the compiler warn about that?

Accepting your fix may open the flood gates to invite all kinds of nonsense.
I mean, what's next? Somebody asking us to change variable names because he's
using a brain-damaged compiler that spits out Mathematica-esque warnings like
"Possible spelling error: identifier 'numy' is similar to existing identifier
'numx'."? There has to be a line drawn somewhere, and I draw it at the point
where the only purpose of a patch is to avoid a (pointless) compiler warning.

Don't get me wrong. I'll gladly replace "while (c = *s++)" with
"while ((c = *s++) != 0)" anytime, because that also makes the code more
comprehensible. But I despise stuff like commenting out variable names,
'UNUSED' macros etc. in code that is 100% OK, just to avoid compiler messages.

Bye,
Christian

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


-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it




More information about the PURRS-devel mailing list