Gabriel Dos Reis wrote:
Roberto Bagnara bagnara@cs.unipr.it writes:
| Gabriel Dos Reis wrote: | > I'm one of those GCC people taking care of the library and I can | > assure you I don't particularly appreciate that style (like some other | > things in the V3 STYLE). So, I would say that you should be very | > careful in drawing conclusions from things you might read in the V3 | > source code -- not every one has the same idea of the styles to be used. | | It is not a matter of style: it is a matter of respect for the users.
I guess it depends on what you define to be irrespectful for users.
Here is a partial definition that applies to the present case. Refusing to write
(1) virtual void destroy(bool /* call_parent */) { }
instead of
(2) virtual void destroy(bool call_parent) { }
*in a header file* is irrespectful to the users. The reason is that (1) is semantically equivalent to (2), conveys the same information to maintainers than (2), and has the advantage of allowing a productive compilation with -W -Wall of g++, with --remarks of Comeau C++, with -w2 of Intel's icc, and so forth.
Given the tone you're taking
Tone? Which tone? I am simply defending a point of view that I believe is quite reasonable. I have reread my messages but I don't see what you are talking about. Please, resist the temptation of nitpicking on my tone and see if you can suggest a viable solution to the issue I am raising.
and the lack of recognizing actual facst,
Facts? Which facts? I was offered no facts: you and others have simply stated that your very personal taste is against things like
void foo(int /* i */) { }
which I don't believe is a fact. OK, you offered the fact that the GNU standard library does not always use the form (1) above: this is a fact. You also stated, but this is not a fact, that you would rather use form (2): something that, I believe, would turn compiling with -W -Wall to a complete nightmare. (I wonder if, to be consistent, you should also advocate the removal of the unused argument warnings from g++.)
I also do not consider a fact the suggestion that we should write a script to filter out warnings for each compiler we use, perhaps with variants for different compilation flags, perhaps changing the scripts to accommodate changes in GiNaC header. Besides being compiler-dependent, should the script to filter out warnings be also dependent on the location where GiNaC is installed? On the line number where (2) occurs? Should all warnings coming from a file called basic.h be silenced? But of course, if GiNaC's developers prefer (2) to (1), we should be prepared to teach the script to ignore also the warnings coming from the 40 (fourty) include files of GiNaC, and we should update the script if they restructure their include files. No: I don't think this is a serious suggestion.
Perhaps the implicit suggestion we have been given is to stop compiling with extra warnings, but we don't want to do it. We did not invent the extra warnings options. We found them there and we discovered that they were very effective in catching errors we and our students make. So we use them with all the compilers we use. We were happy until the day when, around GiNaC 1.0.5, the line of code (2) was inserted...
I guess there is no much interest in continuing this thread.
This is a beautiful oxymoron ;-)
| Huh? Looks like a copy-and-paste error...
No. Just go and check out.
I had checked already: the fragment you included is
template<typename _InputIter, typename _OutputIter> inline _OutputIter __copy(_InputIter __first, _InputIter __last, _OutputIter __result, input_iterator_tag) template<typename _InputIter, typename _OutputIter> inline _OutputIter __copy(_InputIter __first, _InputIter __last, _OutputIter __result, input_iterator_tag)
This is not C++, does not occur anywhere in the file stl_algobase.h released with GCC 3.2 and, not containing a function body, does not show any unused parameter. I guess what you wanted to show is on the CVS sources: fine. Point understood anyway. I keep my fingers crossed in the hope that the GCC developers will resist the temptation of screwing their header files in the name of abstract style considerations that do not take the user's needs into account. All the best
Roberto