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