Marco van de Voort
marcov at stack.nl
Sun Dec 14 16:51:12 CET 2014
In our previous episode, Adriaan van Os said:
> reveals 0 for False and -1 for True, where I had expected 0 for False and
> 1 f
> according to <http://msdn.microsoft.com/en-us/library/eke1xt9y.aspx> the
> respectively in Visual Studio 2013.
There is a C (99?) bool type, and a winapi (and much older) BOOL type. Two
different libraries, two different headers, two different cases :-)
In old SDKs, BOOL was defined in windef.h, but can't seem to quickly find
that in my current 8.1 (that was seriously mangled due to the winrt
Afaik BOOL was implemented for winapi benefit, and the boolean* types for
pascal booleans (0,1)
More importantly, TRUE is generally defined as !FALSE, and vice versa (your
URL mentiones that too), and thus not as succ(TRUE). So even if the values
are successive, that doesn't mean it is ordinal other than being an integer
derived value in older compilers.
> So, there doesn't seem to be a WIndows compatibilty reason to use -1 for
> Delphi has -1 for True, but then it would apply to mode Delphi only).
IMHO using the for loop on a non pascal boolean type is simply wrong. At the
very least the assumption that the false and true are successive, and maybe
even using BOOL as loopvar in the first place.
If I'm on my work machine (that still has a win7 SDK), I'll try to look it
up there too.
More information about the fpc-devel