Author: Miguel A. Ballicora
Date: 21:06:27 12/06/01
Go up one level in this thread
On December 06, 2001 at 23:28:16, Christophe Theron wrote:
>On December 06, 2001 at 23:11:55, Miguel A. Ballicora wrote:
>
>>On December 06, 2001 at 19:43:57, Christophe Theron wrote:
>>
>>>On December 06, 2001 at 13:31:44, Miguel A. Ballicora wrote:
>>>
>>>>On December 06, 2001 at 12:53:14, Severi Salminen wrote:
>>>>
>>>>>Hi!
>>>>>
>>>>>Don't ever, I mean never ever, disable "those stupid warnings you don't want to
>>>>>see anymore because they mean nothing". Well, for some odd reason I had disabled
>>>>>unary operator and type conversion warnings. Now I just removed the #pragma
>>>>>directive and found a major bug! I was using a 32-bit integer as a temporary
>>>>>variable to store a 64-bit bitboard - how smart of me!! Actually I'm surprised I
>>>>>hadn't noticed it before as it should've had corrupted the board representation
>>>>>badly every time there was pawn double move. Well, now my program plays at least
>>>>>5 elos better ;)
>>>>>
>>>>>Severi
>>>>
>>>>What I generally do is try to silence the warnings by rewriting my code
>>>>as long as it is possible. Most of the time it is easy and it results in a
>>>>safer, cleaner and more readable code (at least for me). When I can't, I include
>>>>a local #pragma that I disable immediately after. Generally, I do not need this
>>>>many times. Now, I have only one pragma valid for one line in my entire souce.
>>>>I am pretty sure that I have more undetected bugs that pragmas :-)
>>>>
>>>>Miguel
>>>
>>>
>>>
>>>I do the same, except that I do not use #pragma to silence warnings.
>>>
>>>Whenever possible I rewrite the code so the compiler does not have to issue a
>>>warning. Generally just adding an explicit cast does it, and it is free. In some
>>>cases I have to add an instruction (to initialize a variable that the compiler
>>>thought was not initialized, when actually it was). So I accept a performance
>>>penalty in order to have a clean (warning free) code.
>>>
>>>Naturally my compiler's warning level is set to the maximum.
>>>
>>>I treat warnings the same way I treat errors: I just fix them.
>>>
>>>I don't understand why people write C or C++ programs without setting warnings
>>>to their maximum level. I don't even understand why it is allowed to set the
>>>warning level to a lower value in most C and C++ compilers.
>>
>>I agree with you philosophycally. However, sometimes some warnings are extremely
>>annoying despite that C code is correct.
>>
>>The only pragma I have is this one:
>>
>>#pragma warning (push)
>>#pragma warning (disable : 4146)
>>
>>static int
>>bb_count_bits (BITBOARD a)
>>{
>> int count;
>> UINT32 n;
>>
>> n = a.hf[0];
>> for (count = 0; n; n -= (n & -n))
>> count++;
>>
>> n = a.hf[1];
>> for ( ; n; n -= (n & -n))
>> count++;
>> return count;
>>}
>>
>>#pragma warning (pop)
>>
>>because it does not like negating an unsigned int. That is correct C
>>code described in the standard. I understand that this could be a bug
>>somewhere else, but here I really want to do that and I know
>>what I am doing (I think :-)). I could fix it using ~(n-1) rather than -n
>>but I do not want to change the idiom. Who knows, maybe I should.
>>The point is that I understand if some people turn off some warnings in
>>some particular cases if the use of some characteristic of the language is
>>used heavily. However, turning off the warnings should be strongly discouraged
>>IMHO.
>>
>>Miguel
>
>
>
>Just insert the correct cast and you are done. I think it is less complicated
>than adding code to disable then re-enable the warning.
Unfortunately, in this case I can't. Casting an unsigned int with (signed int)
is implementation defined when it is outside the range. In other words,
it is not portable.
Miguel
>
>You can forget to turn the warning on again and end up in trouble.
>
>Don't forget: if it can happen, then it will happen!
>
>
>
> Christophe
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.