Hi,
Ken Foskey wrote:
I am also concerned that then process will become a template fix.
if( fp = fopen( "file", "r" )) {
can become:
if( (fp = fopen( "file", "r")) ) {
If I assign someone to clean up the error, say a junior programmer
because it is menial, and we have this code:
if( x = 4 ) {
They may very well apply the 'template' solution hiding a useful
warning.
if( (x = 4) ) {
Well, I just assume that the people who do this task are experienced
enough to first understand the code - and only then change it.
- - -
A little sidetrack: I would not suggest to change
if( fp = fopen( "file", "r" )) {
into
if( (fp = fopen( "file", "r")) ) {,
because the first not only issues a warning, but also is probably not
exception safe.
So rather I'd write:
fp = fopen( "file", "r" );
if(fp != NULL) {
to remove the warning.
And then something similar to
fp = fopen( "file", "r" );
if(fp != NULL) {
FileGuard fg(fp); // will close file in destructor
to ensure exception safety.
Nikolai
That useful warning being removed is WORSE than the problem of many
warnings. This gets really tricky when you get into essoteric C++
warnings.
The objective of the push should be to highlight bugs by removing as
many warnings with obvious solutions as possible. If in doubt leave the
warning!
As Pavel has hinted it is possibly better to work through one warning
class at a time, eg assignment bugs. This can be discussed so that the
approach to each is correct, eg don't just bracket them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
