if (-1) returns true

S

Skybuck Flying

Hi,

I came across this C code which I wanted to understand etc it looked like
this:

if (-1) etc

It made me wonder what the result would be... true or false ?

In C and Delphi

False is defined as zero.
True is defined as non zero.

I find this a bit weird since false and negative and true and positive seem
more intuitive.

Think of a lieutenant who asks a question to a soldier, the soldier will
reply:
"Negative" if it's not true.
"Affirmitive" if it's true.

Therefore wouldn't this be more intuitive ?:

False defined as negative or zero.
True defined as positive.

Bye,
Skybuck.
 
J

Jeremy Collins

Skybuck said:
Therefore wouldn't this be more intuitive ?:

False defined as negative or zero.
True defined as positive.

Where did you learn programming?
 
M

Michael Hoffacker

By the way, negative in this context doesnt mean a number < 0 but
declining.
 
J

J French

Hi,

I came across this C code which I wanted to understand etc it looked like
this:

if (-1) etc

It made me wonder what the result would be... true or false ?

In C and Delphi

False is defined as zero.
True is defined as non zero.

Try this little demo :-

procedure TForm1.Button1Click(Sender: TObject);
begin
Case LongBool( 2 ) Of
True : ShowMessage( 'True' );
False : ShowMessage( 'False' );
Else ShowMessage( 'Oops - Bad LongBool' );
End;

Case Boolean( 2 ) Of
True : ShowMessage( 'True' );
False : ShowMessage( 'False' );
Else ShowMessage( 'Oops - Bad Boolean' );
End;

If LongBool( 2 ) Then
ShowMessage( 'Yet this works for LongBool' );

If Boolean( 2 ) Then
ShowMessage( 'And this works for Boolean' );

ShowMessage( 'Which is why it is very unwise'
+' to EXPLICITLY test for "True"'
+#13'Although, sometimes one does. :)'
)

end;
 
S

Skybuck Flying

The fun thing is that this code is buggy occording to the delphi help:

"
A value of type ByteBool, LongBool, or WordBool is considered True when its
ordinality is nonzero. If such a value appears in a context where a Boolean
is expected, the compiler automatically converts any value of nonzero
ordinality to True.
The previous remarks refer to the ordinality of Boolean values, not to the
values themselves. In Delphi, Boolean expressions cannot be equated with
integers or reals. Hence, if X is an integer variable, the statement

if X then ...;

generates a compilation error. Casting the variable to a Boolean type is
unreliable, but each of the following alternatives will work.
"

Note this part in particular ;): "Casting the variable to a Boolean type is
unreliable"

Bye,
Skybuck.
 
S

Skybuck Flying

Jeremy Collins said:
Where did you learn programming?

Behind my computer =D

Fortunately turbo pascal and delphi are great programming languages to learn
to program.

Delphi's help comes to the rescue once again and teaches me how booleans
work:

"
The four predefined Boolean types are Boolean, ByteBool, WordBool, and
LongBool. Boolean is the preferred type. The others exist to provide
compatibility with other languages and operating system libraries.

A Boolean variable occupies one byte of memory, a ByteBool variable also
occupies one byte, a WordBool variable occupies two bytes (one word), and a
LongBool variable occupies four bytes (two words).

Boolean values are denoted by the predefined constants True and False. The
following relationships hold.

Boolean ByteBool, WordBool, LongBool
False < True False <> True
Ord(False) = 0 Ord(False) = 0
Ord(True) = 1 Ord(True) <> 0
Succ(False) = True Succ(False) = True
Pred(True) = False Pred(False) = True
A value of type ByteBool, LongBool, or WordBool is considered True when its
ordinality is nonzero. If such a value appears in a context where a Boolean
is expected, the compiler automatically converts any value of nonzero
ordinality to True.
The previous remarks refer to the ordinality of Boolean values, not to the
values themselves. In Delphi, Boolean expressions cannot be equated with
integers or reals. Hence, if X is an integer variable, the statement

if X then ...;

generates a compilation error. Casting the variable to a Boolean type is
unreliable, but each of the following alternatives will work.

if X <> 0 then ...; { use longer expression that returns Boolean
value }
var OK: Boolean { use Boolean variable }
...
if X <> 0 then OK := True;
if OK then ...;
"

What do they mean with ordinality ?

More text from help files:

"
Ordinal types include integer, character, Boolean, enumerated, and subrange
types. An ordinal type defines an ordered set of values in which each value
except the first has a unique predecessor and each value except the last has
a unique successor. Further, each value has an ordinality which determines
the ordering of the type. In most cases, if a value has ordinality n, its
predecessor has ordinality n - 1 and its successor has ordinality n + 1.

For integer types, the ordinality of a value is the value itself.
Subrange types maintain the ordinalities of their base types.
For other ordinal types, by default the first value has ordinality 0, the
next value has ordinality 1, and so forth. The declaration of an enumerated
type can explicitly override this default.

Several predefined functions operate on ordinal values and type identifiers.
The most important of them are summarized below.

Function Parameter Return value Remarks
Ord ordinal expression ordinality of expression's value Does not take Int64
arguments.
Pred ordinal expression predecessor of expression's value
Succ ordinal expression successor of expression's value
High ordinal type identifier or variable of ordinal type highest value in
type Also operates on short-string types and arrays.
Low ordinal type identifier or variable of ordinal type lowest value in type
Also operates on short-string types and arrays.
For example, High(Byte) returns 255 because the highest value of type Byte
is 255, and Succ(2) returns 3 because 3 is the successor of 2.
The standard procedures Inc and Dec increment and decrement the value of an
ordinal variable. For example, Inc(I) is equivalent to I := Succ(I) and, if
I is an integer variable, to I := I + 1.
"

The order of values ?

Well how I am supposed to know the order of values ?

I can imagine the compiler defining integer values as:

-10 -9 -8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 0

or

0 1 2 3 4 5 6 7 8 9 -1 -2 -3 -4 -5 -6 -7 -8 -9

Etc.

Though this is documented above:

"For integer types, the ordinality of a value is the value itself."

What about booleans... well these little functions give it away:

Ord(False) = 0
Ord(True) = 1

Now back to this statement:

"
A value of type ByteBool, LongBool, or WordBool is considered True when its
ordinality is nonzero. If such a value appears in a context where a Boolean
is expected, the compiler automatically converts any value of nonzero
ordinality to True.
The previous remarks refer to the ordinality of Boolean values, not to the
values themselves. In Delphi, Boolean expressions cannot be equated with
integers or reals. Hence, if X is an integer variable, the statement
"

Especially this part:

"the compiler automatically converts any value of nonzero ordinality to
True"

What is therefore the ordinality of -1 ?

Good question eh ? ;)

Apperently ordinality can be negative as well.

Well at least now I understand how delphi defines booleans and false and
true etc.

However I am not a C programmer and I don't care that much about C... it's
just bitching when one has to read C code :D

I have done my part and explained how Delphi works.

Are you good enough to explain how C works ? ;)

Bye,
Skybuck.
 
K

Krishanu Debnath

[snip non C exaplanation]
However I am not a C programmer and I don't care that much about C... it's
just bitching when one has to read C code :D

I have done my part and explained how Delphi works.

Are you good enough to explain how C works ? ;)

Bye,
Skybuck.
In Boolean context, a false value is inferred when the expression
compares equal to zero otherwise true.

Krishanu
 
J

J French

The fun thing is that this code is buggy occording to the delphi help:
True

Note this part in particular ;): "Casting the variable to a Boolean type is
unreliable"

Well the problem turns up when the data is read from somewhere else,
say from disk or a stream

Also (and this is the nasty) the return value from some Win APIs

Test this little lulu

If ( Boolean( 2 ) = True ) Then
ShowMessage( 'So True is anything but False' )
Else
ShowMessage( 'An unexpected result' );

On balance I don't think it is much of a problem, once one is aware of
it - but it is useful to know.
 
F

Flash Gordon

J said:
Well the problem turns up when the data is read from somewhere else,
say from disk or a stream

Also (and this is the nasty) the return value from some Win APIs

Test this little lulu

If ( Boolean( 2 ) = True ) Then
ShowMessage( 'So True is anything but False' )
Else
ShowMessage( 'An unexpected result' );

On balance I don't think it is much of a problem, once one is aware of
it - but it is useful to know.

Could you please keep your discussions of Delphi off comp.lang.c since
even those of us who *do* program in Delphi are not interested in
discussing it here.

I've set follow ups to alt.comp.lang.borland-delphi since there is
nothing about C in this subthread.
 
J

Jeremy Collins

Skybuck said:
I have done my part and explained how Delphi works.

Uh, thanks.

Are you good enough to explain how C works ? ;)

The same as any other compiled language, when you get down to it.

The point I was hinting at is that you began a rant with some
(probably unknown to you) incorrect assumptions, the most
important of which is the underlying type of your "boolean" value.

It's efficient to fit a "boolean type" into a small space, right?

So why are you assuming a signed type? Why not a byte? What happens
when you assign a negative number to a byte?

Is there a glimmer of light here? Does
FALSE = 0
TRUE = {anything else}
start to make sense?
 
R

Rufus V. Smith

Skybuck Flying said:
Hi,

I came across this C code which I wanted to understand etc it looked like
this:

if (-1) etc

It made me wonder what the result would be... true or false ?

In C and Delphi

False is defined as zero.
True is defined as non zero.

I find this a bit weird since false and negative and true and positive
seem
more intuitive.

Think of a lieutenant who asks a question to a soldier, the soldier will
reply:
"Negative" if it's not true.
"Affirmitive" if it's true.

Therefore wouldn't this be more intuitive ?:

False defined as negative or zero.
True defined as positive.

Bye,
Skybuck.

LOL! I like that "Negative" for false the soldier uses...
However incorrect it may be.

I usually use just 1 or 0 for true or false, 0 being false.

Other folks, wiser than I (at least until I learned the trick), used
!0 as an expression for true.

I like the logic of it. We can pretty much agree that 0
is going to be false (not to be confused with success/failure,
which is a different story altogether).

if 0 is false, then the logical complement, !0 will be true.

(but in a success/failure calling sequence, 0 usually
indicates success, and nonzero failure, the value representing
the error coded reason for failure.)

Rufus
 
B

Bruce Roberts

Therefore wouldn't this be more intuitive ?:

Intuition is the application of the cumulative effect of knowledge and
experience. What is intuitive to one person may be counter-intuitive to
another. Unless all participants posses similar knowledge and experience
(including cultural experience) one should never deem something to be
intuitive to the group.

Regardless. Formal languages are defined and it is far better to consult a
language definition than to rely on one's intuition.

Pascal defines type Boolean as possessing two possible values True and False
such that False < True. Delphi preserves this definition.

-1 is a particular visualization of a bit pattern. The same bit pattern can
be visualized as 4294967296, as True, and as 4 characters (the specifics of
which depend on collating sequence). While one person may "intuitively" view
all bit patterns as 4 byte integers, many others don't.
 
C

CBFalconer

Bruce said:
.... snip ...

Regardless. Formal languages are defined and it is far better to
consult a language definition than to rely on one's intuition.

Pascal defines type Boolean as possessing two possible values True
and False such that False < True. Delphi preserves this definition.

Pascal defines an enumeration: boolean = (false, true). This
means that ord(true) is 1 and ord(false) is zero. Also that true >
false. For Pascal this makes the least significant bit the crucial
one for logical decisions. C, on the other hand, lumps all
non-zero values into the category 'true'.
From ISO10206:

c) Boolean-type. The required type-identifier Boolean shall
denote
the Boolean-type. The Boolean-type shall be an ordinal-type.
The values shall be the enumeration of truth values denoted by
the required constant-identifiers false and true, such that
false is the predecessor of true. The ordinal numbers of the
truth values denoted by false and true shall be the integer
values 0 and 1 respectively.

Note that boolean is not a reserved word, but a pre-defined type.
As such it can be user redefined.

OT for c.l.c. F'ups set.
 
H

Heinrich Wolf

In C boolean operators are defined to return 0 or 1,
because you can assign this value to ordinals of any bit width,
whether signed or not.

The if statement regards any non-zero value as true.
You can easily understand this,
if you search for similar behaviour of
bool, bit-fields and sets.
If you use an ordinal as bit-field,
which also represents a set,
you can test, if the set is non-empty.
The result is true on any non-zero bit in the field.
This is any non-zero ordinal value.
 
M

Martin Harvey (Demon account)

I find this a bit weird since false and negative and true and positive seem
more intuitive.

Ah, but signed or unsigned? If you're going to interpret booleans as a
numeric quantity, then what sort of numeric quantity makes sense?

If you actually want the interpretation you have, then before doing
the IF test, simply invert the bits and AND with 0x80000000.
Think of a lieutenant who asks a question to a soldier, the soldier will
reply:
Therefore wouldn't this be more intuitive ?:

Maybe, but not when you think in terms of bits. The zero flag is
maintained on many processors throughout most operations and is quick
and easy to check (and to calculate).

MH.
 
S

Stephen Sprunk

Skybuck Flying said:
In C and Delphi

False is defined as zero.
True is defined as non zero.

I find this a bit weird since false and negative and true and positive seem
more intuitive.

CPUs in the real world have very efficient instructions for setting and
testing zero vs. nonzero, so it makes sense for C to take advantage of that.

If you were to use negative vs positive, the test degenerates to looking at
whether the sign bit is zero or nonzero anyways. That method also requires
that all boolean variables are signed, whereas the C method works equally
well with signed and unsigned variables.

S
 
F

Fao, Sean

Skybuck Flying wrote:

Therefore wouldn't this be more intuitive ?:
False defined as negative or zero.
True defined as positive.

#include <stdio.h>

int main(void)
{
unsigned int i;

if (i = -1)
printf("Always true\n");
else
printf("Buy a new computer\n");

return 0;
}
 
J

J French

On Fri, 4 Mar 2005 13:48:14 -0600, "Stephen Sprunk"

If you were to use negative vs positive, the test degenerates to looking at
whether the sign bit is zero or nonzero anyways. That method also requires
that all boolean variables are signed, whereas the C method works equally
well with signed and unsigned variables.

Have you ever done any Assembler ?

Amazing the crap people come up with nowadays
- it reminds me of yesterday

Sprunk - you are talking out of your fundamental oriffice

And, Sprunk, now I am drunk - but tomorrow I might be sober
- as for you understanding the crud you are spouting
- chances are zilch

You annoyed me, and I'm pretty sure that you cannot work out why.
 
S

Stephen Sprunk

J French said:
On Fri, 4 Mar 2005 13:48:14 -0600, "Stephen Sprunk"



Have you ever done any Assembler ?

Yes, quite a bit.
Amazing the crap people come up with nowadays
- it reminds me of yesterday

Sprunk - you are talking out of your fundamental oriffice

And, Sprunk, now I am drunk - but tomorrow I might be sober
- as for you understanding the crud you are spouting
- chances are zilch

Instead of ad hominem attacks, why don't you point out where I said
something wrong? Perhaps in your admitted drunkenness you failed to
understand something.
You annoyed me, and I'm pretty sure that you cannot work out why.

I have no clue.

S
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,160
Messages
2,570,889
Members
47,421
Latest member
StacyTaver

Latest Threads

Top