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

[Richard B. Kreckel]

Ciao everybody,

Folks, is such a heated discussion really appropiate in this case?

For my own part, I really don't care very much whether we comment out this
silly parameter name or not.  But I do think that Christian Bauer raised
some strong points against this patch.

Adding `-Wunused-parameter' will show the one warning Roberto Bagnara is
complaining about when compiling your own programs with GiNaC headers.
Note that when compiling GiNaC itself it shows a lot of similar warnings
for code like this one (from normal.cpp):

ex basic::smod(const numeric &xi) const
{
    return *this;
}

Hence, for reasons of coding style uniformity we wouldn't just change the
one line in basic.h, but also all the other ones.  Since in the case of
virtual functions a compiler would have to have knowledge of all derived
classes in order to suppress such a warning we are very unlikely to see
this ever fixed at the compiler side.

Anyways, isn't this particular warning easily grepped away?

On Mon, 23 Sep 2002, Roberto Bagnara wrote:
> No: that the parameter is not being used in the function body.
> This catches a significant number of mistakes.  Many people use
> g++ and compile with -Wall and they agree that it is a nice thing
> to be warned about that cases.

As a little known historical aside: why is `-Wunused-parameter' not
switched on with `-Wall'?  Because `-Wall' is the set of all warnings that
can be switched on without being triggerd when compiling GNU/Emacs!
Sounds silly?  Maybe it is.  But this is how such choices are made some
times: by religious arguments.  I seriously doubt that this practice helps
anybody at all.

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

Remember that this code merely estabilishes a vtbl entry so inlining
cannot take place anyways.  Why not suggest another patch?  Wouldn't it be
totally equivalent to remove the empty default code and put it in
basic.cpp?  I'm sure you can come up with an acceptable solution for your
problem!

[...]
> Because omitting the argument name is the ISO standard compliant way of
> specifying that the argument is _intentionally_ unused.

Hmm, can you provide evidence in support of what you are implying?

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

You are really blessed if you can afford to base your choice of software
on such arguments.

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

You're welcome.  But please keep in mind that we are generally quite open
for suggestions/patches/additions.

Best wishes
         -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>