One last time: annoying warning

[Roberto Bagnara]

Richard B. Kreckel wrote:
 > Folks, is such a heated discussion really appropiate in this case?

No, it is not.  But I am fed up about the attitude of your colleague.

 > 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;
 > }

It is overwhelmingly clear that GiNaC itself can adopt any programming
style that fits the needs of their developer.

 > Hence, for reasons of coding style uniformity we wouldn't just change the
 > one line in basic.h, but also all the other ones.

Here is where you are missing the point.  Your .cpp files. are one
thing.  A completely different thing are the .h header files you give
to your users.  These, to be really useful, must suite the needs of as
many compilers as possible with as many combinations of compilation
options as possible.  The ideal is that they must be good for
everyone.  The headers should not impose any requirement apart from
the use of a standard conforming compiler; for the rest they should be
100% bullet proof.  I am sure you understand that.  (And if you don't
it means only we have too different views on how a truly professional
library should be written.)  BTW: do you know that all your header
files are not standard conforming?

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

At least you realize that.  Your friend, instead, prefers insulting
the GCC developers because of their "stupid compiler".  I look forward
to see his own compiler ;-)

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

Yes, it is.  But that is not the point.

 >>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!

Hem, Richard, it is not up to us to suggest the very right patches to
GiNaC.  We have raised a number of issues concerning GiNaC: that is
our duty as collaborative users.  It is up to GiNaC's developers to
understand the issues and find the right solutions.  We are also
writing our share of free software so let us make a deal: you provide
the world with the best computer algebra library ever, we provide the
best polyhedra library ever (http://www.cs.unipr.it/ppl/) and will
soon provide the best recurrence relation solver ever (that is what
the PURRS project aims at).

 >>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?

I am not sure to understand you.  However, here is the proof: the ISO
C++ standard says that unused parameters need not be named (see
[8.4p5]).  Moreover, there is no way you can directly refer (i.e., not
resorting to an alias) to an unnamed parameter in the body of the
function.  Thus, if the programmer has omitted the name of a
parameter, he/she has expressed quite clearly his/her intention not to
use it in the body of the function.

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

For our project we need clear interfaces, unambiguous documentation,
very formal specifications of just anything, and an easy way of
continuing with the development style we have chosen (which, in
particular, includes running with lots of warnings switched on).  All
of us have been unsatisfied concerning one or more of these things, so
we have decided not to tie our project with GiNaC too much.  Yesterday
we did not receive satisfactory answers about the _exact_
specification of some GiNaC functions.  Today the great programmer
refuses to _mutilate_ his code and we do not know what will happen
tomorrow.  If you understand that, then please start treating us like
the evolute users and fine developers we are and not like people that
has time to waste and has chosen to waste it by annoying you.  Our
projects are significantly younger than yours, but we treat our users
very differently, especially those that show the good will and
dedication necessary to come up with patches and proposals (whether or
not they turn out to be the best possible ones).
All the best

    Roberto

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