Re: bool or BOOL in MFC projects
"Joseph M. Newcomer" <firstname.lastname@example.org> ha scritto nel messaggio
Windows was carefully designed so every BOOL value returned from the API
was either 0 or
1. The Win9x people couldn't be bothered with doing the job right, so
they just returned
any value they felt like, calling any nonzero value "not-false". So the
main reason we
have problems was slovenly programming in the fake operating system.
Given it only took a
couple instructions to do the job right, it was really an extreme case of
trumping correct programming.
I don't have your historical perspective.
However, reading from a random BOOL-returning API, like ::IsChild:
the documentation clearly states that:
"If the window is a child or descendant window of the specified parent
window, the return value is *nonzero*.
If the window is not a child or descendant window of the specified parent
window, the return value is zero."
I think that when we program with an API, the *interface* documentation is
what matters. We must respect the interface, and it seems that the interface
is clear in that case.
It's like what I would define IMHO a "buggy" COM code, when people do e.g.
HRESULT hr = pSomeInterface->SomeMethod(...);
if ( hr == E_FAIL )
or if ( hr == DD_OK ) ...
IMHO, we should write more "robust" code, using ad hoc helper macros like
FAILED() and SUCCEEDED(), e.g.
if ( FAILED(hr) ) // for generic failure