Do not simply quiet warnings by adding type casts or other means. Instead, understand the reason for the warning and consider a better approach, such as using matching types and avoiding type casts whenever possible.
Code: Select all
Even if you've fixed every compiler error and linker error your compiler gives you, it may still give you "warnings" (the cheeky bastard). These warnings won't keep your code from compiling (unless you ask the compiler to treat warnings as errors), and you might be tempted to just ignore them. There are, however, some good reasons not to do so. In doing so, I'll also cover some specific examples of the types of warnings you might face, what they mean, and how to fix them.
Catch Bugs Before Testing
The great thing about compiler warnings is that they are often indicators of future bugs that you would otherwise see only at runtime. For instance, if you see your compiler complaining about an "assignment in conditional" then it might mean that you've written
Catch Bugs that are Hard to Find in Testing
Compilers will always warn you about things that might be difficult to find during testing. For example, your compiler can warn you that you are using an uninitialized variable; this can be hard to find in testing if you declare your variable far from the spot you first use it. (Note that "using" an uninitialized variable simply means getting its value; it's perfectly fine to initialize it. In fact, that's the solution to the problem.)
Lessons to Take Away
While you've picked up a few tips for combating compiler warnings, the real message here should be the mindset you should have--catch bugs as early as possible, and take advantage of your tools, like the compiler, that tell you exactly where problems are before you discover something mysterious during testing. Sometimes there may be no need for you to set your compiler to fail on any warnings, but if you use automated scripts for building your program or tend to ignore the compiler unless it fails, then this might be a useful thing to do. You'll have to look at your compiler documentation for exactly how to set this up; on gcc and g++, all you need to use is the -Werror flag ("treat warnings as errors").
Furthermore, if you don't understand what a compiler warning means, it's probably best to trust that the compiler is telling you something valuable. I've had experiences where I was convinced that my code was correct and wasn't entirely sure what the compiler could be complaining about. But after investigating my compiler's complaints, I realized I had made a subtle mistake in a boolean expression that would have been nearly impossible to hone in on when debugging--it was much easier to catch the mistake while the code was fresh in my mind code rather than hours or possibly days later when I might (with luck) have found the bug due to the mistake.
( Alex Allain : Cprogramming.com )
A simple case in HMG
\HMG\SOURCE\REPORT
Try to change warnings to Level 1 on the file: report.hbp ( -w0 to -w1 )
Them use buildlib.bat to compile the Lib (maybe you need to adjust path's in .bat file)
Code: Select all
#
# .hbp : Harbour Projet File
#
-workdir=\hmg\obj
-hblib
-inc
-o../../lib/report
-Iinclude
-D__HBIDE__
-w1
-es2
h_report.prg
tprint.prg
You check the sources to solve this problem but find nothing (a real problem)...
Solution: Just go to the end of file: H_REPORT.PRG and delete last lines (below: return ncol ): delete this line: #include "tprint.prg"
Now try to build Lib again...
Wow: I love Warnings
Progressively we can adjust warnigs to higher level... resulting in Better and Safer code... plus faster and Stable projects....
