Re: [fpc-devel] BOOL / Comparing booleans - bad style

Pascal is about readability. A sentence like "if this variable is true do that" reads better than "if this variable do that". The danger is only when the variable type and the constant representing TRUE are not compatible. In C, since TRUE is usually an untyped #define, that can be hard to deter

Re: [fpc-devel] BOOL / Comparing booleans - bad style

Hello folks! MS>>> But the silly C programmer did "if (a == TRUE)". JN>> I have seen this kind of nonsense way too often, >> even in Pascal code. >>May I sincerely ask to include a hint/warning feature such as >> "Comparing booleans - bad style" >>in order to notify the programmer to think twic

Re: [fpc-devel] BOOL

In our previous episode, Jasper Neumann said: > I have seen this kind of nonsense way too often, even in Pascal code. > May I sincerely ask to include a hint/warning feature such as >"Comparing booleans - bad style" > in order to notify the programmer to think twice. > This warning should be al

Re: [fpc-devel] BOOL

Hello folks! Michael Schnell wrote 2014-12-15 09:28:05: > But the silly C programmer did "if (a == TRUE)". I have seen this kind of nonsense way too often, even in Pascal code. May I sincerely ask to include a hint/warning feature such as "Comparing booleans - bad style" in order to notify the

Re: [fpc-devel] BOOL

Am 14.12.2014 um 16:51 schrieb Marco van de Voort: 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 the same respectively in Visual Studio 2013. There

Re: [fpc-devel] BOOL

Mark Morgan Lloyd wrote: I agree that zero and false are generally equivalent, except possibly in the case of unix shell scripts where it gets messy. It's arguably unsafe to ever cast true to a number or enumeration, and possibly the best behaviour would be to ensure that the compiler always h

Re: [fpc-devel] BOOL

Adriaan van Os wrote: Marco van de Voort wrote: 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 the same respectively in Visual Studio 2013. There

Re: [fpc-devel] BOOL

Michael Schnell wrote: Now, in C (which does not feature a native boolean type, but boolean operators) a *decent* boolean decision is e.g. "if (a)". But the silly C programmer did "if (a ==TRUE). Now the boolean variable "a" imported from Delphi was presumed as FALSE instead of TRUE. An inte

Re: [fpc-devel] BOOL

Marco van de Voort wrote: For variant bools it is definitely -1. There is a comment about that too somewhere. I found Yet another type, VARIANT_

Re: [fpc-devel] BOOL

On 12/14/2014 04:51 PM, Marco van de Voort wrote: More importantly, TRUE is generally defined as !FALSE, and vice versa IMHO, (usually, ubiquitously ) FALSE is defined as a binary zero of appropriate bit count (hence unambiguously) , while TRUE is defined as "not FALSE" and hence it's binary r

Re: [fpc-devel] BOOL

On Mon, December 15, 2014 07:58, Adriaan van Os wrote: > Michael Van Canneyt wrote: >>> Well, true is -1 and false 0 :) I wonder if we should forbid it in fpc >>> mode ... >> >> We should. IMHO ByteBool is unsigned so >=0... > > I suggest to change the internal value of TRUE to 1 for all boolean ty

Re: [fpc-devel] BOOL

In our previous episode, Adriaan van Os said: > Michael Van Canneyt wrote: > >> Well, true is -1 and false 0 :) I wonder if we should forbid it in fpc > >> mode ... > > > > We should. IMHO ByteBool is unsigned so >=0... > > I suggest to change the internal value of TRUE to 1 for all boolean type

Re: [fpc-devel] BOOL

Michael Van Canneyt wrote: Well, true is -1 and false 0 :) I wonder if we should forbid it in fpc mode ... We should. IMHO ByteBool is unsigned so >=0... I suggest to change the internal value of TRUE to 1 for all boolean types, except in mode delphi. Then "for b:= false to true" works as on

Re: [fpc-devel] BOOL

On Sun, 14 Dec 2014, Florian Klämpfl wrote: Am 14.12.2014 um 21:22 schrieb Michael Van Canneyt: On Sun, 14 Dec 2014, Florian Klämpfl wrote: Am 14.12.2014 um 20:25 schrieb Michael Van Canneyt: On Sun, 14 Dec 2014, Florian Klämpfl wrote: Am 14.12.2014 um 18:05 schrieb Adriaan van Os:

Re: [fpc-devel] BOOL

Am 14.12.2014 um 21:22 schrieb Michael Van Canneyt: > > > On Sun, 14 Dec 2014, Florian Klämpfl wrote: > >> Am 14.12.2014 um 20:25 schrieb Michael Van Canneyt: >>> >>> >>> On Sun, 14 Dec 2014, Florian Klämpfl wrote: >>> Am 14.12.2014 um 18:05 schrieb Adriaan van Os: >> IMHO using the for

Re: [fpc-devel] BOOL

On Sun, 14 Dec 2014, Florian Klämpfl wrote: Am 14.12.2014 um 20:25 schrieb Michael Van Canneyt: On Sun, 14 Dec 2014, Florian Klämpfl wrote: Am 14.12.2014 um 18:05 schrieb Adriaan van Os: IMHO using the for loop on a non pascal boolean type is simply wrong. At the very least the assumptio

Re: [fpc-devel] BOOL

Am 14.12.2014 um 20:25 schrieb Michael Van Canneyt: > > > On Sun, 14 Dec 2014, Florian Klämpfl wrote: > >> Am 14.12.2014 um 18:05 schrieb Adriaan van Os: 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

Re: [fpc-devel] BOOL

On Sun, 14 Dec 2014, Florian Klämpfl wrote: Am 14.12.2014 um 18:05 schrieb Adriaan van Os: 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.

Re: [fpc-devel] BOOL

Am 14.12.2014 um 18:05 schrieb Adriaan van Os: >> 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. > > The compiler accepts it. Can somebody

Re: [fpc-devel] BOOL sorry

Sorry for the multiple posts, my email program indicated "failure" on send. Regards, Adriaan van Os ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL

Marco van de Voort wrote: 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 the same respectively in Visual Studio 2013. There is a C (99?) bool type,

Re: [fpc-devel] BOOL

Marco van de Voort wrote: 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 the same respectively in Visual Studio 2013. There is a C (99?) bool type,

Re: [fpc-devel] BOOL

Marco van de Voort wrote: 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 the same respectively in Visual Studio 2013. There is a C (99?) bool type,

Re: [fpc-devel] BOOL

Am 14.12.2014 um 17:21 schrieb waldo kitty: > > my understanding of TRUE and FALSE has always been > > FALSE = 0 > TRUE = !FALSE > > we have, in some of our code, used this to determine a "truth level" > returned by some routines... in other words, when we're detected TRUE > we've then looked

Re: [fpc-devel] BOOL

my understanding of TRUE and FALSE has always been FALSE = 0 TRUE = !FALSE we have, in some of our code, used this to determine a "truth level" returned by some routines... in other words, when we're detected TRUE we've then looked at the value of the variable returning TRUE... depending

Re: [fpc-devel] BOOL

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 the > same > respectively in Visual Studio 2013. There is a C (99?) bool type, and a winapi (and

[fpc-devel] BOOL

While doing some Win32 programming I ran into a for loop that didn't work var b: bool; for b := False to True do ... whereas var b: bool; for b := False downto True do ... did work. The reason seems to be the internal value of False and True for BOOL, as