Thorsten Froehlich <tho### [at] trfde> wrote:
> Using all gcc warning is pointless.

  I tend to disagree.

  In our project, which I'm working, we have (at this moment) 71695 lines of
code in 359 source files. We get 0 warnings when compiling with the flags
"-Wall -W -pedantic -ansi". I don't remember making any compromises in order
to keep gcc happy.
  So it's perfectly possible to avoid the warnings.

> In particular the implicit type conversion warnings are the biggest nonsense
> in both gcc and VC because C as well as C++ explicitly define which implicit
> type conversions exist and how they behave.

  You seem to misinterpret the idea behind the warning.
  Yes, the standard defines how explicit conversions work. However, the
idea behind the warning is that converting from a bigger type to a smaller
type loses information and when this is done implicitly, it's often a mistake
from the part of the coder (ie. the coder didn't notice that he is assigning
for example a double to an integer, thus losing information, which could
result in the code not working).
  What gcc is doing is to recommend you to make the conversion explicit.
That has absolutely no effect in performance, as it's converted to the
exact same code internally, and it makes your code more clear: You are
kind of "documenting" that you are indeed making the conversion deliberately
and that it's not just a programming mistake, and most importantly, it's like
a comment to someone reading your code that "note: there's a conversion done
here". The reader doesn't have to wonder if you just made a mistake there or
you are doing it on purpose.
  Of course the most important use of this warning is when you actually make
the mistake and the compiler warns you and then you can fix it, instead of
wondering why your code doesn't work.

  I see nothing wrong with this.

>  It is obvious that a compiler
> should not warn about perfectly legal and well behaving code by default.

  You seem to think that a warning is the same thing as an error.
  If the code is perfectly legal, then the compiler must not issue an error,
naturally. However, I see nothing wrong in the compiler issuing warnings on
suspicious code, which may be a mistake from the part of the programmer.
  For example, this is perfectly legal:

void foo()
{
  do_something;
  return;
  do_something_else;
}

  However, that looks quite suspicious. The last command is never executed
(and the compiler will most probably just optimize it away). However, it's
quite improbable that the programmer made that deliberately (what's the
point in writing code which is clearly never executed?).
  Of course with code that is as straightforward as that it's pretty obvious.
However, with more complicated code, with many ifs etc, it might not be
as obvious that a certain part is never executed, and thus it's most probably
a programming mistake. The warning is quite useful.

  Warnings are not about the code being legal or illegal. It's about helping
the user with suspicious-looking code.
  Warnings have often helped me catching mistakes at compilation time, which
is a great help.

  Don't bother telling me that a warning has never helped you catching a
mistake, because I won't believe it.

> In particular important is that explicit conversions, if used incorrectly to
> get rid of compiler warnings can degrade performance (because you could be
> tempted to first bit-mask integers for example).

  Even if someone would make that needless bit-mask, any modern compiler
is probably so smart that it will optimize it away.

  Even though many times compilers are quite poor at optimizing some things,
in other cases they are surprisingly clever. For example, I once tested a
code like this:

(with a, b and c being unsigned ints):

  a = (b<<c)|(b>>(32-c));

  When I looked at the asm code generated by the compiler, to my surprise
it had compiled that complicated statement as one single rotation command,
instead of making a substraction, two shifts and an or.

>> 2. "multi-character character constant"

> These are nonsensical compiler warnings for perfectly legal and portable
> code as long as the platform being used has 32 bit or bigger ints.  As
> POV-Ray will not run on 16 bit processors, you can just disable those
> warnings, like the compiler developers should have done in the first place
> when the target code is for a platform whose ints (or other variable sizes)
> can hold the data without problems.

  Are you sure that there may not be a problem with endianess when using
multi-character constants?
  For example, consider a code like this:

FILE* infile = fopen(...);
int fileID;
fread(&fileID, 4, 1, infile);
if(fileID != 'RIFF') { error("Wrong file type"); }

  Will that work in a high-endian/low-endian system?

  If it does not work, then the warning is very useful.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message