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 > same > 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 additions). 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 > True > 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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
