[PURRS-devel] Re: One last time: annoying warning

[Roberto Bagnara]

Gabriel Dos Reis wrote:
> Roberto Bagnara <bagnara at 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

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it