Board index » delphi » Confused by logic - seeking some inspiration

Confused by logic - seeking some inspiration

(TP7) I'm writing a unit (BiosDA) providing an object (oBiosDataArea)
that reads the contents of the BIOS data area beginning at segment
400h, and returns them in a meaningful manner, via "properties". Among
them, the interface has one such as

        function CapsLockActive: boolean;

which can tell whether CapsLock is activated or not.

I write a testing program which just shows whether Caps Lock is
Active, in 2 ways:

- as a boolean (the actual CapsLockActive function value)
- as "Active" (standing for True) or "Not Active" (standing for False)

Here is the program:

---------------------
USES
  BiosDa;  {the unit containing the object}

VAR
  BiosDataArea: oBIOSDataArea;  {an instance of the object}

BEGIN
  writeln(BiosDataArea.CapsLockActive);

  if BiosDataArea.CapsLockActive=True then
    writeln ('Active')
  else
    writeln ('Not Active');
END.
-------------------

CapsLock is off. I run the program and get

        FALSE
        Not Active

Allright.

I activate CapsLock, run the program, and get

        TRUE
        Not Active

instead of

        TRUE
        Active

What kind of 'ABC' of TurboPascal am I missing here?

 

Re:Confused by logic - seeking some inspiration


Quote
Manuel Algora wrote:

> (TP7) I'm writing a unit (BiosDA) providing an object (oBiosDataArea)
> that reads the contents of the BIOS data area beginning at segment
> 400h, and returns them in a meaningful manner, via "properties". Among
> them, the interface has one such as

>         function CapsLockActive: boolean;

> which can tell whether CapsLock is activated or not.

> I write a testing program which just shows whether Caps Lock is
> Active, in 2 ways:

> - as a boolean (the actual CapsLockActive function value)
> - as "Active" (standing for True) or "Not Active" (standing for False)

> Here is the program:

> ---------------------
> USES
>   BiosDa;  {the unit containing the object}

> VAR
>   BiosDataArea: oBIOSDataArea;  {an instance of the object}

> BEGIN
>   writeln(BiosDataArea.CapsLockActive);

>   if BiosDataArea.CapsLockActive=True then
>     writeln ('Active')
>   else
>     writeln ('Not Active');
> END.
> -------------------

> CapsLock is off. I run the program and get

>         FALSE
>         Not Active

> Allright.

> I activate CapsLock, run the program, and get

>         TRUE
>         Not Active

> instead of

>         TRUE
>         Active

> What kind of 'ABC' of TurboPascal am I missing here?

???

It is funny. But maybe it is a clap on the finger for your very
sophisticated :-) programming...

You know: the = operator delivers a boolean result, ok?

If you compare two booleans with = then you will retrieve a boolean
result. If true=true is the same as If true  :-))))

But this is an OT issue only.

The other point: possibly the function itself (you did not post
it here) modifies the bit, erroneously. Or you have not initialized
the object at all???????
--
Franz Glaser, Glasau 3, A-4191 Vorderweissenbach Austria +43-7219-7035-0
Muehlviertler Elektronik Glaser.  Industrial control and instrumentation
http://members.eunet.at/meg-glaser/           mailto:meg-gla...@eunet.at
http://www.geocities.com/~franzglaser/ http://members.xoom.com/f_glaser/

Re:Confused by logic - seeking some inspiration


Quote
Manuel Algora <m...@encomix.es> wrote in message

news:38329f9f.2258765@news.ctv.es...

Quote
>...
> BEGIN
>   writeln(BiosDataArea.CapsLockActive);

>   if BiosDataArea.CapsLockActive=True then
>     writeln ('Active')
>   else
>     writeln ('Not Active');
> END.
> -------------------
> ...
> I activate CapsLock, run the program, and get

> TRUE
> Not Active

> instead of

> TRUE
> Active

> What kind of 'ABC' of TurboPascal am I missing here?

A boolean can be true without being equal to True.

A boolean variable occupies 8 bits. That means that it can have 256
different values. Two of these are legal, False and True. It's probably bad
practise to assume that False=0 and True=1 (because it's bad to assume
anything more than you have to - the more assumptions you make the more
likely it is that someone will break one of them sometime) but that's what
they are and it's in the manual.

Now, if the compiler has a boolean variable which it knows must be true or
false, and its value is not false, it assumes it to be True. In other words,
any ordinal value of a boolean variable other than 0 will be true - but not
necessarily equal to True. Try

Var
  i : integer;
  b : boolean;
begin
  For i := -3 to 3 do
  Begin
    b := Boolean(i);
    Writeln(ord(b):5,b:7,b=true:7);
  End;
end.

to see what I mean. This uses a bad boolean cast to set illegal values in b
and then print them out. b is true except when its ordinal value is 0 but it
is only equal to True when its ordinal value is the ordinal value of True,
ie 1.

This works for Write and for checking the variable in expressions: "if
BiosDataArea.CapsLockActive then..." would have worked in you code above.
You don't have to compare a boolean with anything in Pascal, just use it. If
you _must_ compare it with something, compare it with False only, if you
have a habit of doing that then your habit will be correct if you move to C.
But you are testing that the value returned by BiosDataArea.CapsLockActive
has the specific value True.

If BiosDataArea.CapsLockActive is correct then it should always return False
or True, but this is clearly not happening. I'd guess that you are returning
the value got by masking off the relevant bits of the BIOS variable, cast to
a Boolean. Instead you should be returning the value of a boolean
expression: CapsLockActive := (x and Mask)<>0;

FP

Re:Confused by logic - seeking some inspiration


Hi,

on Wed, 10 Nov 1999 at 16:40:31 o'clock, Manuel Algora wrote:

Quote
> I activate CapsLock, run the program, and get

>    TRUE
>    Not Active

> instead of

>    TRUE
>    Active

> What kind of 'ABC' of TurboPascal am I missing here?

Your program is correct, but who knows what the function does. Functions can
have side effects. Try assigning the function value to a boolean variable,
then print that variable and use it for the test. If you get a correct
result, your function "falsifies" the byte in the BIOS RAM. Or post the
function.

 - Sebastian

--
YOUR AD HERE!

Re:Confused by logic - seeking some inspiration


On Wed, 10 Nov 1999 16:40:31 GMT, m...@encomix.es (Manuel Algora)
wrote:

Quote
> (TP7) I'm writing a unit (BiosDA) providing an object (oBiosDataArea)
> that reads the contents of the BIOS data area beginning at segment
> 400h, and returns them in a meaningful manner, via "properties". Among
> them, the interface has one such as

>    function CapsLockActive: boolean;

> which can tell whether CapsLock is activated or not.

> I write a testing program which just shows whether Caps Lock is
> Active, in 2 ways:

> - as a boolean (the actual CapsLockActive function value)
> - as "Active" (standing for True) or "Not Active" (standing for False)

> Here is the program:

> ---------------------
> USES
>   BiosDa;  {the unit containing the object}

> VAR
>   BiosDataArea: oBIOSDataArea;  {an instance of the object}

> BEGIN
>   writeln(BiosDataArea.CapsLockActive);

>   if BiosDataArea.CapsLockActive=True then
>     writeln ('Active')
>   else
>     writeln ('Not Active');
> END.
> -------------------

> CapsLock is off. I run the program and get

>    FALSE
>    Not Active

> Allright.

> I activate CapsLock, run the program, and get

>    TRUE
>    Not Active

> instead of

>    TRUE
>    Active

> What kind of 'ABC' of TurboPascal am I missing here?

You didn't post the code of  CapsLockActive. The problem is therein.
You probably do some assembler programming in there assign a number >1
as "True" to the boolean return value. Like here:

function active:boolean;assembler;
asm
    mov al, 2
end;

begin
  writeln(active);        { true }
  writeln(active=true);   { false }
end.

The byte value of the constant TRUE is 1. TP will interpret any value
<>0 in a boolean variable as "true" but the comparison of such a value
with the constant TRUE will only yield "true" if the value is 1
because the comparison via = of booleans is done as a byte comparison
and not as a "logical comparison".

Anyway a comparison with TRUE is always bad programming style because
it is redundant. Write a simple and natural

        if CapsLockActive then
          writeln('active')

or change the return value of the function to a "true" TRUE. In BASM
you may use the constant 'true', too.

Regards
Horst

Re:Confused by logic - seeking some inspiration


On Wed, 10 Nov 1999 18:25:21 -0000, "Frank Peelo" <fpe...@indigo.ie>
wrote:

Quote
> If BiosDataArea.CapsLockActive is correct then it should always return False
> or True, but this is clearly not happening. I'd guess that you are returning
> the value got by masking off the relevant bits of the BIOS variable, cast to
> a Boolean. Instead you should be returning the value of a boolean
> expression: CapsLockActive := (x and Mask)<>0;

Or use the unknown data types bytebool, wordbool, longbool (only TP
7.0).

The cast

                var b: boolean;
                    x: byte;

                b:=bytebool(x)  { or wordbool, longbool }

unlike boolean() - converts any value <> 0 to a true TRUE, i.e. it
beaves like the C++ cast bool().

Regards
Horst

Re:Confused by logic - seeking some inspiration


I guess you are absolutely right in all you say. Thanks for the lesson
(and thanks to all the other that replied to my message). The function
is an assembler one, and I was just masking the value in AL before
returning, assuming any value other than 0 meant True.

Now, it's a PITA programming with True limited to a particular value
-at least if you jump from one compiler to another, as I use to do.
Most (all?) BASICs, for instance, use -1 for True. Which means code is
not immediately portable. A converter Basic <> Pascal might do a good
job, but even so, a program that relies on a particular value for True
would not work properly when converted to another programming
language. I may think of 2 cases in which this problem may arise:

- Arithmetic functions: I have written functions in BASIC which sum up
a whole lot of statements in just one very long formula full of
boolean operators, which rely on True being equal to -1, as a
computational value. These would return an erroneous result if
directly ported to TurboPascal.

- Assembler functions: If you assign with Pascal statements
CapsLocksActive:=True, then everything should go allright. But when
programming CapsLockActive return value in a function with the
assembler directive, the door for an error lies open. As was my case,
assuming <>0 equals True. But even if I put 1 for True, a TurboPascal
assembler function would not be immediately portable to PowerBasic,
which also has inline assembler, but uses -1 for True -or is it 1?
Hard to remember.

Thank you very much to you and everybody once more.

On Wed, 10 Nov 1999 18:25:21 -0000, "Frank Peelo" <fpe...@indigo.ie>
wrote:

Quote

>Manuel Algora <m...@encomix.es> wrote in message
>news:38329f9f.2258765@news.ctv.es...
>>...
>> BEGIN
>>   writeln(BiosDataArea.CapsLockActive);

>>   if BiosDataArea.CapsLockActive=True then
>>     writeln ('Active')
>>   else
>>     writeln ('Not Active');
>> END.
>> -------------------
>> ...
>> I activate CapsLock, run the program, and get

>> TRUE
>> Not Active

>> instead of

>> TRUE
>> Active

>> What kind of 'ABC' of TurboPascal am I missing here?

>A boolean can be true without being equal to True.

>A boolean variable occupies 8 bits. That means that it can have 256
>different values. Two of these are legal, False and True. It's probably bad
>practise to assume that False=0 and True=1 (because it's bad to assume
>anything more than you have to - the more assumptions you make the more
>likely it is that someone will break one of them sometime) but that's what
>they are and it's in the manual.

>Now, if the compiler has a boolean variable which it knows must be true or
>false, and its value is not false, it assumes it to be True. In other words,
>any ordinal value of a boolean variable other than 0 will be true - but not
>necessarily equal to True. Try

>Var
>  i : integer;
>  b : boolean;
>begin
>  For i := -3 to 3 do
>  Begin
>    b := Boolean(i);
>    Writeln(ord(b):5,b:7,b=true:7);
>  End;
>end.

>to see what I mean. This uses a bad boolean cast to set illegal values in b
>and then print them out. b is true except when its ordinal value is 0 but it
>is only equal to True when its ordinal value is the ordinal value of True,
>ie 1.

>This works for Write and for checking the variable in expressions: "if
>BiosDataArea.CapsLockActive then..." would have worked in you code above.
>You don't have to compare a boolean with anything in Pascal, just use it. If
>you _must_ compare it with something, compare it with False only, if you
>have a habit of doing that then your habit will be correct if you move to C.
>But you are testing that the value returned by BiosDataArea.CapsLockActive
>has the specific value True.

>If BiosDataArea.CapsLockActive is correct then it should always return False
>or True, but this is clearly not happening. I'd guess that you are returning
>the value got by masking off the relevant bits of the BIOS variable, cast to
>a Boolean. Instead you should be returning the value of a boolean
>expression: CapsLockActive := (x and Mask)<>0;

>FP

Re:Confused by logic - seeking some inspiration


Quote
On Thu, 11 Nov 1999 00:08:18 +0000, Higgi...@ftc-i.SpAmZaP.net wrote:
> On Wed, 10 Nov 1999 19:35:55 GMT, in
> <3829b106.3445...@news.btx.dtag.de>, horst.krae...@t-online.de (Horst
> Kraemer) wrote:

> >The byte value of the constant TRUE is 1. TP will interpret any value
> ><>0 in a boolean variable as "true" but the comparison of such a value
> >with the constant TRUE will only yield "true" if the value is 1
> >because the comparison via = of booleans is done as a byte comparison
> >and not as a "logical comparison".

> AFAIK, FALSE = 0 and TRUE = NOT FALSE, in the sense that NOT is one's
> complement negation.

Please make a difference between "truth" of a condition and the value
of the Pascal constants FALSE and TRUE. The ord-value (byte value) of
TRUE is 1 in Pascal by definition of the language, and ord(FALSE)=0.

In TP logical evaluation will treat every ordinal value <>0 which
happens to be in a boolean variable b and which is different from 0 as
"true". But it wont compare equal to TRUE if ord(b)<>1 because
comparison with =<> of booleans is done bitwise and not
"truth-value"-wise.

Of course

        TRUE = NOT FALSE

evaluates to TRUE as a Pascal instruction because the logical operator
NOT converts 0 to 1 and everything different from 0 to 0. But what you
probably mean is that everything which is <>FALSE will be interpreted
as "true". This is a very different meaning of the text "TRUE=NOT
FALSE".

You are confusing the logical NOT which is applied when the operand
has type boolean and the bit-operator NOT which applies if the
operator is a number.

        bytevar := NOT bytevar

evaluates to $FF if bytevar was 0 because NOT on non-booleans toggles
_every_ bit of the operand. But

        boolvar:=NOT boolvar

evaluates to TRUE (i.e. to 1) if boolvar was FALSE (0).

Regards
Horst

Re:Confused by logic - seeking some inspiration


Quote
Manuel Algora <m...@encomix.es> wrote in message

news:382ae539.20079960@news.ctv.es...

Quote
> I guess you are absolutely right in all you say. Thanks for the lesson
> (and thanks to all the other that replied to my message). The function
> is an assembler one, and I was just masking the value in AL before
> returning, assuming any value other than 0 meant True.

In general, if you are given a boolean value you _should_ assume that any
value other than False (0) _means_ true, but you were assuming that those
values _were_equal_to_ true, which is a different thing. Do not compare with
True, compare with False if you have to explicitly compare at all - ie
b<>False is a more reliable test than b=True. This is not specifically a
Pascal issue, it also applies to C and to other languages. Ideally, in
Pascal, the boolean should never have values other than False and True, but
as you have seen, people make mistakes, assume the whole world runs like C
where 0=false and any non-0=true and if you have to make an assumption
you're safer going with the same assumption as everyone else. The function
returning the wrong value is still wrong and should be fixed but at least
the program will work.

But if you _do_ write a function which returns a subrange type, return a
value of that subrange type. Otherwise someone using the function may get
confused, as you have seen :)

When writing code, say what you mean. If you say "boolean" you mean
something that is either false or not false and you don't care how the
compiler handles that internally. If you say Integer, you are specifying
values which may be used in arithmetic as well as being compared.

In TP's inline assembler, you can assign al the value of True without having
to worry about True's ordinal value - example:

Function x(vlu:shortint):boolean; assembler;
asm
  mov al, vlu
  cmp al, False
  je @1
  mov al, True
@1:
end;

If you don't want to add such extra code to your function, you can return a
ShortInt, documented as being 0 for false and undefined non-zero for true.
Then the function's user will not expect a specific True value. This is
likely to take the same amount of code as a boolean comparison: in the test
program

Var
  b1 : ShortInt;
  b2 : Boolean;
Begin
  if b1<>0 then
  Begin
  End;
  if b2 then
  Begin
  End;
End.

the comparisons compile to

PROGRAM.5:  if b1<>0 then
  cs:0008 803E500000     cmp    byte ptr [0050],00
  cs:000D 7400           je     PROGRAM.8 (000F)
PROGRAM.8:  if b2 then
  cs:000F 803E510000     cmp    byte ptr [0051],00
  cs:0014 7400           je     PROGRAM.11 (0016)

Same code internally for both, at least in this compiler. Since compiler
writers also want one which will not cause unnecessary grief you would
expect the boolean to be compared with 0 in most other compilers too.

Quote
> Now, it's a PITA programming with True limited to a particular value
> -at least if you jump from one compiler to another, as I use to do.
> Most (all?) BASICs, for instance, use -1 for True. Which means code is
> not immediately portable.

Definitely not all! And sometimes values have changed in one language from
one revision of a compiler to the next (although not in TurboPascal). But if
you only ever compare to False, this is not a problem. (What does PITA stand
for?)

Quote
> ...
> - Arithmetic functions: I have written functions in BASIC which sum up
> a whole lot of statements in just one very long formula full of
> boolean operators, which rely on True being equal to -1, as a
> computational value. These would return an erroneous result if
> directly ported to TurboPascal.

That is icky, even in BASIC. There was some excuse for it in the days of the
4K PET but none nowadays.

If you come across the book "Writing Solid Code" by Steve Maguire, read the
"Treacheries Of The Trade" chapter, especially "The Old Paint-Stirrer Trick"
(p159-160). (Then read the rest of the book too...) Boolean types are there
for a reason, and it's not addition. If you want addition, use ShortInt. As
I showed earlier, comparison of ShortInt with 0 is as efficient as checking
a boolean, at least in TP.

Quote
> - Assembler functions: If you assign with Pascal statements
> CapsLocksActive:=True, then everything should go allright. But when
> programming CapsLockActive return value in a function with the
> assembler directive, the door for an error lies open. As was my case,
> assuming <>0 equals True. But even if I put 1 for True, a TurboPascal
> assembler function would not be immediately portable to PowerBasic,
> which also has inline assembler, but uses -1 for True -or is it 1?
> Hard to remember.

Again, if it's only going to be used for false/not-false then use a boolean,
and code the function so that it _does_ return a boolean. Otherwise use an
integer.

FP

Re:Confused by logic - seeking some inspiration


Quote
<Higgi...@ftc-i.SpAmZaP.net> wrote in message

news:ZQYqOBMRY=s4qxmi8juF1vkCeRt3@nntp.ftc-i.net...

Quote
> On Wed, 10 Nov 1999 19:35:55 GMT, in
> <3829b106.3445...@news.btx.dtag.de>, horst.krae...@t-online.de (Horst
> Kraemer) wrote:

> >The byte value of the constant TRUE is 1. TP will interpret any value
> ><>0 in a boolean variable as "true" but the comparison of such a value
> >with the constant TRUE will only yield "true" if the value is 1
> >because the comparison via = of booleans is done as a byte comparison
> >and not as a "logical comparison".

> AFAIK, FALSE = 0 and TRUE = NOT FALSE, in the sense that NOT is one's
> complement negation.  That's the only definition I can find in the RTL
> for BP7.  This means TRUE = 11111111 binary, FF hex, 255 decimal, all
> bits in the byte on, etc.

You're looking in the wrong place... for BP7, English version, try the
language guide, page 26: "Because Booleans are eenumerated types, these
relationships hold:
- False < True
- Ord(False) = 0
- Ord(True) = 1
- Succ(False) = True
- Pred(True) = False"

But it's still a bad idea to rely on any of these things unless you have to.
Not everyone uses Borland Pascal, and other languages also have the concept
of True and False but implement them differently. So code that relies on
Ord(True) = 1 will be confusing to non-BP programmers.

FP

Re:Confused by logic - seeking some inspiration


Im Artikel <38329f9f.2258...@news.ctv.es>, m...@encomix.es (Manuel Algora)
schreibt:

The possible reasons have already been mentioned in other answers.

Try to modify your code from:

Quote
>  if BiosDataArea.CapsLockActive=True then
>    writeln ('Active')
>  else
>    writeln ('Not Active');

to something like:

  case BiosDataArea.CapsLockActive of
  True :  writeln ('Active');
  False: writeln ('Not Active');
  else    writeln ('Neither');
  end;

I think that then you'll get the correct printout, with regards to the value of
the CapsLockActive property. The correct printout with regards to your intended
results should result from code like:

  if BiosDataArea.CapsLockActive then //no "= True" here!
    writeln ('Active')
  else
    writeln ('Not Active');

As somebody already mentioned, Pascal booleans are stored as bytes, with more
possible values besides True and False. In order to maintain the logical
relationship of "True = Not False", the compiler can test a byte only against
one value, either True or False, and then map the result of = or <> into True
and False. When this test is made against zero, then = maps to False, when the
test is made against 1 (True), then = maps to True.

Boolean values also exist in Delphi as ByteBool etc., with the explicit
definition, that any non-zero value is treated as True. I think that the TP
compiler will do the same as almost any other compiler, i.e. treat any non-zero
value as being logical True, even if it is not exactly equal to the constant
True, which has the unique value of 1.

DoDi

Re:Confused by logic - seeking some inspiration


JRS:  In article <80eert$7d...@ezekiel.eunet.ie> of Thu, 11 Nov 1999
13:04:50 in news:comp.lang.pascal.borland, Frank Peelo

Quote
<fpe...@indigo.ie> wrote:
>You're looking in the wrong place... for BP7, English version, try the
>language guide, page 26: "Because Booleans are eenumerated types, these
>relationships hold:
>- False < True
>- Ord(False) = 0
>- Ord(True) = 1
>- Succ(False) = True
>- Pred(True) = False"

>But it's still a bad idea to rely on any of these things unless you have to.
>Not everyone uses Borland Pascal, and other languages also have the concept
>of True and False but implement them differently. So code that relies on
>Ord(True) = 1 will be confusing to non-BP programmers.

Wirth says false < true ; but, AFAICquicklyS, no more than that.

Borland's statement, while true, is a /non sequitur/; they could have
started with     type boolean = (False, Dunno, True) ;

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.

Re:Confused by logic - seeking some inspiration


Im Artikel <382ae539.20079...@news.ctv.es>, m...@encomix.es (Manuel Algora)
schreibt:

Quote
>Most (all?) BASICs, for instance, use -1 for True. Which means code is
>not immediately portable.

Why not? All compilers, that I know of, treat non-zero as *logical* true. This
covers both cases, whether the constant "True" is defined as +1 or -1. Have you
ever heard of a language, that defines "True" to have the value zero???

You should have learned in the meantime, that it's not a good idea to compare
so-called boolean values against True or False. Instead you should use only IF
statements like:
  "if <whatever_the_compiler_accepts_as_boolean> then..."
to test for logical true or false values.

The only exceptions from the above rule are very, very type safe languages,
which treat boolean values as being absolutely different and incompatible with
bytes or other data types. In this case, the compiler will flag the "if ..." as
an error, and only then you are asked to convert the expression into something
else, that the compiler accepts as boolean.

DoDi

Re:Confused by logic - seeking some inspiration


Im Artikel <382ae539.20079...@news.ctv.es>, m...@encomix.es (Manuel Algora)
schreibt:

Quote
> which rely on True being equal to -1, as a
>computational value.

Some languages specify, that the outcome of a comparison can only be True or
False, i.e. can only have the *value* of one of these constants.

This means, that any Basic interpreter/compiler or any C compiler will always
create code from comparisons, which assures that the result of the comparison
can only be one of the constant values True or False, and cannot be anything
else. This will usually result in many machine instructions, as you can find in
all compiled Basic or C sources. In C code you'll find, that a comparison will
always check the CPU flags, and translate these into either 0 or 1 values, and
a possibly following IF statement again tests this resulting value against
zero.

Since these intermediate instructions are superfluous in many cases, Delphi
instead optimizes all boolean expressions, and accepts in an IF statement any
non-zero value as True. The outcome of a comparison is only converted into the
exact range False..True, when the result is to be for some other purpose.
That's one of the reasons, why Delphi (or Pascal) programs really can execute
faster than C programs!

DoDi

Re:Confused by logic - seeking some inspiration


Im Artikel <3829cc68.10456...@news.btx.dtag.de>, horst.krae...@t-online.de
(Horst Kraemer) schreibt:

Quote
>The cast

>            var b: boolean;
>                x: byte;

>            b:=bytebool(x)  { or wordbool, longbool }

>unlike boolean() - converts any value <> 0 to a true TRUE

BEWARE!

I tested this some months ago, and things turned out to be different!

The Borland documentation does not normally distinguish type *casts* from type
*conversions*. In the above case Delphi doesn't apply a type conversion, but
only a type cast. The type cast tells the compiler, that the value IS of the
casted type, and that consequently no further checking or conversion is
required. The above code definitiely allows to *store* any arbitrary value into
a Boolean variable. You can test yourself, when you "b := boolean(127)", and
afterwards cast the stored value back with "x := byte(b)". When you try to
evaluate Inc(b) or to retrieve Succ(b) or Pred(b) and assign these to another
Byte or Boolean variable, you'll find some strange and also different
exceptions, depending on what byte-values have been deposited in the Boolean
variable before.

Try to assign values in the range 126..130 or -2..+2 to b, in your sample code,
and then invoke Inc, Dec, Pred, Succ, and watch what different range and
overflow exceptions can result from only the different value, residing in that
innocent boolean variable.

DoDi

Go to page: [1] [2]

Other Threads