Richard B. Kreckel wrote:
BTW: do you know that all your headerfiles are not standard conforming?
Hmm, which are the non-conforming parts in our header files?
You are violating [17.4.3.1.2], for instance.
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.
You should take a closer look to the two messages by Christian Bauer.
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.
No, there is no need you contact your friends or that I contact mine (for we would then need ways to check who of them has it bigger). What is important is that the GCC people taking care of the standard library do the right thing. Since they know that someone may very legitimately wish to compile with, e.g., -W -Wall, they write code like
virtual iter_type do_get_time(iter_type __s, iter_type /*__end*/, ios_base&, ios_base::iostate& /*__err*/, tm* /*__t*/) const { return __s; }
(standard library released with GCC 3.2, locale_facets.h, lines 1101 ff.)
static void deallocate(void* __p, size_t /* __n */) { free(__p); }
static void* reallocate(void* __p, size_t /* old_sz */, size_t __new_sz) { void* __result = realloc(__p, __new_sz); if (0 == __result) __result = _S_oom_realloc(__p, __new_sz); return __result; }
(stl_alloc.h, lines 120 ff.), ..., you will find hundreds of examples like that. Naturally, I am really thankful they do that. We also do that. Many others do that. You could also do that... now, immediately, without hurting no one in your current user base (and without wasting our and your time that way).
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.
I was not referring to the prem() issue in particular and in fact our answer to that unsatisfactory exchange is in preparation. There are many other things that have not been answered properly, starting from a precise and unambiguous definition of "polynomial" and going on that way. And also, replying by email is only part of the solution. If we have to really depend on GiNaC we need the specifications to become part of GiNaC's documentation. In other words, we are rather uninterested about what GiNaC does _today_: we need too know precisely what is the intended behavior of everything. If this kind of "contract with the user" does not go into GiNaC's documentation there is a risk tomorrow someone comes, changes the behavior and pretends not having inserted a bug for reasons like "Hey, I never specified what 'q' is!", "Hey, I have never said expand() would do that and that!" and so forth.
Can we stop this childish academic flame war now, please? Please!
We can stop it. I am not sure I understand what do you mean by "childish" and "academic". If by "childish" you mean that I am showing too much how the great programmer pissed me off and how annoyed I am to have to maintain our version of GiNaC and live with the sense of insecurity given by the lack of full documentation, then I agree with you. It would be perhaps look more professional to simply unsubscribe the mailing lists and go back doing more productive work. However, I disagree the issues we have been raising are "academic" in the negative sense it is usually attributed to that word. Yes, I teach computer science in the academia, but
a) writing header files so as to suit the needs of as many users as possible, and b) ask for and provide clearly specified interfaces
are not "academic" things in that sense. They are, to tell the entire truth, very basic stuff in and outside the academia. In my humble but not so humble opinion, of course.
Back to useful work now. Let us communicate with the sources from now on (that will also look less childish). We will study your commits to GiNaC's repository and will take care of our repository. A thin layer of software between us and GiNaC (we are writing it these days) will help us clearly identifying which services we require from a computer algebra package. Then we will try to understand whether we can collect enough information so as to ensure that we can implement these services _reliably_ using GiNaC (I hope so, of course). All the best
Roberto