Peter Lupton NCH Swift Sound wrote:
> But I have been going through other reports from the 'bug book' which I ask
> my programmers to log. Another case which explicit bools would solve would
> be (in Win32)...
>
> HANDLE hFile = CreateFile(...);
> if (!hFile) return;
>
> If the compiler had forced the writer to make a real comparison, I am sure
> the bug would never have made it into release. The problem here is
> INVALID_HANDLE_VALUE is -1 not 0.
It wouldn't help if the test was "corrected" to this:
if (hFile==0) return;
or
if (!bool(hFile)) return;
which I can imagine happening very easily if someone is modifying a
whole code base to conform to the new rules. Once they've "corrected"
it like that, it compiles again and the bug remains unfixed. If someone
has made the mistake of thinking the invalid value is 0, I think that's
unrelated to whether ints convert to bool. Code review seems like the
best place for this bug to be caught IMHO. The difficulty of verifying
the correct handling of magic numbers returned as error codes is an
argument for using exceptions. If you need to use functions like
CreateFile that don't throw, then wrap them in another function that
does and then you only have to verify that the right value is checked in
that one place. C++ provides better ways to avoid this error than
disabling int -> bool conversions (again, IMHO.)
As for your strcmp() example, that would break all code that says:
if (!strcmp(s,t))
Unless you make operator!(int) return bool (which would seem sensible to
me,) but then your HANDLE example wouldn't be caught.
Personally I don't think the pros outweigh the cons of this idea.
Regards,
jon
