
|
Some coding books advocate zero warnings at the highest warnings level setting. Is this possible? I think not. I have seen some people resolved “conversion from 'double' to 'float'” warning by doing a float cast. They could have solve this problem by using all floats or all doubles, however we do use libraries, we do not have control over some libraries, especially third party libraries. For example, float m_f; m_f = (float *)a_double; The problem is by doing a cast, you are silenting the compiler by saying, “yes I know it is wrong but I am very sure a_double's value will not exceed a float's value.” On closer examining the class and library it is using, it only has 2 float member variables and all the casting from double are to be assigned to these 2 member variables. What I seen to be the more correct way to solve this problem, other than casting, is make these 2 variables to be doubles type. Anyway, converting 2 floats(32 bits type) into 2 doubles(64 bits type), you only increase the memory requirement by 8 bytes. It is also much simpler than adding all the castings which need to be there. So the correct way of solving the “conversion from double to float”, “conversion from int to short” and “< : signed/unsigned mismatch” is to change the type of variable to match the other type, ie if that is possible. For example, // Wrong way for( int i=0; i<(int)vec.size(); ++i ) { .... } // Correct way: size_t is the same unsigned type as vec.size() returns for( size_t i=0; i<vec.size(); ++i ) { .... } If you use casting to resolve these type mismatch warning, you might as well use pragmas to silent the warnings, that is what pragmas are used for! When something has gone wrong and you cannot figure it out why, you can remove the pragmas and re-enable the warnings back. With casting, you can't! Zero warnings to me, is an “hard to achieve” ideal because things are not always clear cut. I will always try my best to reduce warnings to the minimum, but I would rather leave some unresolvable warnings there, so that I know where to look if something goes wrong. <div class="ForumMod">modified on Monday, March 30, 2009 5:52 AM</div>
|
|
|
|

|
Wong Shao Voon wrote: warnings
Warning is an indication of a potential weakness in the code. The strength of the chain is normally determined by its weakest point right? Also, we normally need to strengthen the fortress at those segments where the foe has more abilities to conquer. Here the foe is the vulnerability or a bug.
Hence normally it is recommended to 'Treat warning as errors'.
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|