Ciao again,
On Thu, 26 Sep 2002, Roberto Bagnara wrote: [...]
The headers should not impose any requirement apart fromthe 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 headerfiles 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 alsowriting 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@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 programmerrefuses 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 likethe 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.