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

[Richard B. Kreckel]

Ciao again,

On Thu, 26 Sep 2002, Roberto Bagnara wrote:
[...]
>            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.)

I understand that and we do agree.

>                              BTW: do you know that all your header
> files are not standard conforming?

Hmm, which are the non-conforming parts in our header files?

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

Oh, we appreciate GCC and the work of the developers very much over here
-- a point that has frequently been made clear on this list.

I would bet that the GCC developers would agree with him on this
particular unused parameter issue -- but this is speculative.  If you
insist, I may contact some of the developers who I happen to know
quite well personally.

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

Sorry, I just realized [*] that recent versions of GCC do a pretty good
job at optimizing even this inlined code when possible.  So my previous
suggestion about moving the body is not a good one.  At the moment I don't
have another one.  If one occurs to me I will reconsider the issue---until
then my time is too costly.

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

Sorry, we cannot fulfill such a deal.   ;-)

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

I was actually hoping for an authoritative suggestion rather than a vague
option...

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

Please do read that thread ("Documentation of prem()" on the list
ginac-list at ginac.de) again.  The answer seemed perfectly clear to me: `q'
is not the quotient, but the polynomial pseudo-quotient of `a' and `b'
which can be thought of as a generalization of the former for GCD
purposes.  That thread ended with a question wich was not answered from
your side, by the way.

>                                         Today the great programmer
> refuses to _mutilate_ his code and we do not know what will happen
> tomorrow.

Rest assured, you won't see any real mutilation of the code.  We are not
Micro$oft, after all!

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

Come on, please.  Almost any suggestion/patch/addition you've made has
been added to the sources.  And those were more important issues.  And we
will certainly continue to consider all suggestions/patches/additions in
the future.

Can we stop this childish academic flame war now, please?  Please!

Regards
     -richy.

[*] Through timing and looking at code sizes and comparing the generated
    assembler -- though not fully understanding it.  That would require
    much more time which I don't have.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>