Hi! (Ah, this is great. I haven't had a good flame war for years! :-) On Mon, Sep 23, 2002 at 08:26:46PM +0200, Roberto Bagnara wrote:

Christian Bauer wrote:

...

5) Mutilates perfectly valid code in a feeble attempt to keep some nitpicking compiler's trap shut.

"Mutilates"?! Putting the argument name within comments "mutilates"?

Changing code for the *sole* purpose of getting rid of a compiler warning (a warning, remind you; not an error, not a compiler bug, but a *warning*. Warnings mean nothing. They are produced by a program that doesn't even try to 'understand' the code. Yes, warnings are useful in 99% of all cases. This is one example of where they aren't.) isn't my idea of elegant software development.

...

6) Doesn't make the code any more transparent. Rather the opposite.

It makes clear that the argument is _intentionally_ unused.

To whom? To your compiler, perhaps (because someone programmed it to behave that way). Not to me.

Pretty obvious in the specific case, but, more generally, not using function arguments may happen (and does happen) also by mistake.

Yes, but...

...

Unused parameters are to be expected when overloading functions.

So what?

So a C++ compiler should know not to complain about that.

...

What is it 'warning' us about, anyway? That the parameter is dispensable and can be removed?

No: that the parameter is not being used in the function body.

D'oh...

This catches a significant number of mistakes.

*Potential* mistakes. There is definitely no mistake here. I still fail to see how this warning is supposed to be useful _in this specific case_. We are not dealing with a 200+ line function here where one of the parameters might accidentally have been confused with a similarly named local variable. This function's body is empty. Any intelligent being looking at the code can immediately tell that "call_parent" is unused, because the function, well, doesn't do anything at all. There is absolutely no need to provide any more information about the unusedness of that parameter.

Many people use g++ and compile with -Wall and they agree that it is a nice thing to be warned about that cases.

I also compile my stuff with -Wall every now and then, but then I sort the messages produced into three categories: 1) "Oops. That really is a bug. Thank <insert your deity here> for these warnings!" 2) "Not a bug, but gcc has a point here. Changing the code might make it more readable/transparent/portable." 3) "Bogus warning. Stupid compiler. No cookie. That's why I don't have -Wall in the makefile." Your matter falls into category 3, I'm afraid...

...

There's absolutely *nothing* whatsoever wrong with that line of code.

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.

Are we on the same page here? I define the usefulness of code by the results it produces, or by the potential for useful results it may have in the future. Not by how much output the build process spews out in the case that someone, somewhere activates _optional_ gizmos on his or her tools.

...

Your 'fix' only serves to outsmart your compiler's warning heuristics.

It is not a heuristics in the usual sense: unused arguments are always flagged when these warnings are enabled. And this is so by design. The same functionality is available in other C++ compilers. Guess why.

Because a compiler is a mindless automaton that translates an algorithm into a different representation? Because a compiler can't (and shouldn't) know why that algorithm was written down in the exact way it was in the source file? Because compiler writers are well aware of that fact and have added an option to suppress these warnings?

...

The function still has one unused parameter. Why doesn't the compiler warn about that?

Because omitting the argument name is the ISO standard compliant way of specifying that the argument is _intentionally_ unused.

Yeah, right. It says so in the standard: "If you want your compiler to shut the frell up about this stuff, we recommend you put your variable names in comments.". I don't think so. (Whoa, wait! Hold your fire! That last comment was meant ironically. I know what you wanted to say. :-)

While omitting the argument altogether causes an information loss, omitting it by commenting it out is perfectly OK.

...except that it obfuscates the source.

Instead you are choosing to disrespect users and contributors of GiNaC (and the GCC authors as an extra bonus) by imposing your religious arguments upon them.

And you are imposing your compiler's imbecility upon us... Do I tell you how you have to indent _your_ code just because it happens to be misformatted in the editor _I_ am using? No, I don't. You'd probably say "Your editor sucks, dude. Use another one, or at least configure it properly.". And you'd be right. (And how exactly did I disrespect the GCC authors?)

This is a serious mistake for anyone and for a library provider is even worse.

I'm thankful for any help offered, but I choose to reject patches that seem pointless to me. I acknowledge that your intentions in proposing this patch are good, I read it, I gave it some thought, but I've come to the conclusion that it's a kludge that I'd rather not have in our code. My suggestion still is to suppress the compiler warnings if they annoy you, or to find a more appropriate way to deal with them.

Anyway, starting from now, the PURRS project will reduce its dependence on GiNaC as much as possible.

Yeah, go play in your own sandbox! And, I tell you what: We will reduce our use of PURRS here to zero! Now, how does that feel? (Wait, come to think of it, we never used PURRS in the first place... What is this 'PURRS', anyway?). ;-)

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

Isn't that precisely one of the things CVS was designed for? To summarize: - The code in question is 100% valid - I also don't think there's any risk of it being misinterpreted - Compiler warnings are nothing more than hints, not divine revelations; they are therefore to be a) subjected to a critical examination b) taken with a grain of salt - In this case, the warning is pointless - Problems should preferrably be fixed at their place of origin - In this case, the problem lies with the compiler, not with the code - 'Fixing' the compiler is trivial: it has an option to not complain about this (which is actually the default setting, but that's only marginally relevant here) - Therefore, the solution is to change the compiler options. Case closed. That's all, folks. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

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 -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

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 -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it