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

Richard B. Kreckel wrote:

...

                        BTW: do you know that all your header

files 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