Re: bool or BOOL in MFC projects
"Joseph M. Newcomer" <newcomer@flounder.com> ha scritto nel messaggio
news:fj2hm3lk9mcgj815nloua87n27e7joum6l@4ax.com...
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
sloppy thinking
trumping correct programming.
Hi Joe,
I don't have your historical perspective.
However, reading from a random BOOL-returning API, like ::IsChild:
http://msdn2.microsoft.com/en-us/library/ms633524(VS.85).aspx
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
...
Giovanni