number.
But then you are assuming that TRUE == 1, which I was trying to avoid.
Not that that is an unreasonable assumption (in most cases), but the #define version should work on any supposed C compiler, even if it believes that TRUE is -1.
Kind regards,
Tanya
Completely standard. See ISO7185 (standard) and ISO10206 (extended, but compatible with ISO7185). Unfortunately the most popular "Pascal" provider, Borland, did not adhere to the specifications.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
about
Of course, you're entirely correct. At the same time, C has been around a long time, and has enough flexibility to allow programmers several ways to get the same task done. It's not surprising that C has developed some quirky idioms over the years.
One can complain about the idioms, or one can be happy that the language allows programmers that much freedom of expression. There's a reason the Pascal/Ada family isn't more widely used.
At the same time, there's probably such a thing as too much freedom of expression - I've had to maintain some extremely disgusting Perl code in my time. In general I just commented the old stuff out and rewrote it in a less idiomatic style.
Kelly
Is that why Borland was wildly popular while "standard" Pascal was an also-ran?
Kelly (ducking)
The C standard makes it clear that !0 is always 1. Why are you trying to avoid relying on the C standard in this matter?
Every C compiler believes, no *knows*, that !0 is 1 in all cases. No exceptions.
-- Göran Larsson http://www.mitt-eget.com/
This rather lengthy thread just humbly reminds us that "I don't understand it" doesn't necessarily mean "It's badly written".
To go a bit further, just because we don't understand something, doesn't mean that this thing is wrong. Just because it took us hundreds of thousands of years to figure out that the Earth was round, doesn't mean that it should have been flat instead, to save us all some sweating.
And would you be so kind as to quote the corresponding ISO paragraph?
"tanya" wrote in news:bni50t$a11$ snipped-for-privacy@newshost.mot.com:
Unless you are using a nonstandard C compiler, then, by definition, FALSE is 0, and TRUE is 1. Yes, other nonzero values will be treated as true in a conditional test, but, the valye that a boolean expression must return is either 0 or 1. This is by definition of ANSI standard C. Any C compiler you used that did differently was not ANSI C.
-- Richard
This rather lengthy thread just humbly reminds us that "I don't understand it" doesn't necessarily mean "It's badly written".
To go a bit further, just because we don't understand something, doesn't mean that this thing is wrong. Just because it took us hundreds of thousands of years to figure out that the Earth was round, doesn't mean that it should have been flat instead, to save us all some sweating.
"Neil Bradley" wrote in news: snipped-for-privacy@corp.supernews.com:
[snip]
if (a) statement else statement
This is four lines that I must parse.
lval = cond ? !0 : 0;
This is one line that the brain easily "chunks" in one pass.
I simply disagree with your statement of how many passes it takes to comprehend something as fundamental as the the ternary operator.
Regards.
-- - Mark -> --
For relational operators:
6.5.8.6 Each of the operators < (less than), > (greater than), = (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.For equality operators:
6.5.9.3 The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence. Each of the operators yields 1 if the specified relation is true and 0 if it is false. The result has type int. For any pair of operands, exactly one of these relations is true.HTH
-- Morris Dovey West Des Moines, Iowa USA C links at http://www.iedu.com/c Read my lips: The apple doesn't fall very far from the tree.
Similarly you might ask why there are so many Windows systems out there, or why non standards compliant C systems have not survived. Borland supplied something that was cheap, convenient, and fast. It would have been no harder to also make it compliant, but they didn't, probably for marketing (a la MS) reasons. At any rate, this is completely OT here.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
Depends what you mean by "type check." For example, given your definition:
BOOL b;
BOOL read() { BOOL retval; retval = 42; return retval; }
int test() { BOOL b; b = read(); return b; }
must compile successfully, and test must return 42. There is nothing wrong with this code as far as the standard is concerned.
The compiler, however, is free to complain about anything it wants to. A clever compiler might recognize that 42 is outside the defined enumerated range for BOOL, and might complain about it. But it's not required to do so. And it can't refuse to compile it.
C99 defines a new type, _Bool, that does what you really want. The standard header stdbool.h typedefs this as "bool" and defines the new keywords "true" and "false".
Regards,
-=Dave
-- Change is inevitable, progress is not.
Grant Edwards wrote in news:3f99ae7e$0$41284$ snipped-for-privacy@newsreader.visi.com:
Only if we _know_ our C compiler is compliant to the latest spec. Many compilers, especially 8 bit embedded compilers, evaluate to 0 or
-1, not 0 or 1.
Jeff.
Latest spec??? You must be joking!
Quoting from "The C Programming Language", (c) 1978:
Section 2.6 Relational and Logical operators:
The unary negation operator ! converts a non-zero or true operand into 0, and a zero for false operand into 1.
Section 7.6 Relational operators
The operators < (less than), > (greater than), = (greater than or equal to) all yeild 0 if the specified relations is false and 1 if it is true.
Section 7.7 Equality operators
The == (equal to) and != (not equal to) operators are exactly analogous to the reltional operators except for their lower precedence. (Thus a
What in the world are you talking about, man? The 1/0 thing goes back to the very genesis of C- Kernighan & Ritchie..
K&R 2.6
"By definition, the numeric value of a relational or logical expression is 1 if the relation is true, and 0 if the relation is false."
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
You left out the operator in question (logical negation, "!"). In n869, thats 6.5.3.3p5:
The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E).
Regards,
-=Dave
-- Change is inevitable, progress is not.
Yes, and for a simple reason: negation. It's easy to negate a boolean value with a 'NOT' instruction.
NOT 0 = (FF...)FFh = -1
Although, for optimisation reasons, a boolean "true" can be anything that is not 0, not necessarily -1. Might prove useful in some cases.
Not only that, but even on the latest C compiler, any non-zero integer will be treated as a "true" boolean value, which makes the standard a little incongruent in my opinion.
For instance, 'if (a + b)' will be a 'true' condition if a != -b. Of course, (a + b) can be any value, and not just 0 or 1.
Which is why I say: either you use a boolean type, in which case you know what to expect, or you use an integer type. Mixing the two can be a bit confusing.
'a == b' evaluates to a boolean type. But using a boolean value as an integer is kinda risky. That's my opinion. That's why expressions like 'c = (a == b)' are perfectly ok in my eyes, but stuff like 'c = (a == b) + d' is not.
What really happens though is that "a+b" is an integer, and the expression wants a boolean. The computer then applies builtin integer-to-boolean conversion rules with no typecasting required. Ie, "5" is not a boolean value, but it is trivally cast to a boolean.
This is analogous to adding a 'char' to an 'int'; the char is trivially converted to an int before the addition is done.
--
Darin Johnson
Laziness is the father of invention
Can you name one? I can't. And I use some weird ones...
I'm not sure what your point is here.
If you want all 1's, use the bitwise negation operator (~) rather than the logical negation operator. But there are other dangers. Note that !2 == !1, but ~2 != ~1. That's one reason why we have both logical and bitwise flavors of & and |.
If you're talking about assembly language efficiency, it depends on the underlying processor architecture. It's nearly or exactly as efficient to use XOR with 1.
it find to where know you Forth, want you If.
The committee had two choices: Have a single "true" value and everything else is "false", or have a single "false" value and everything else is "true." I think they made the right choice, especially in the face of existing C implementations. You may disagree.
More often, this feature is used in an expression like "if (mask & 0x18)" which will be "true" if either (or both) bits 3 and
4 are set in "mask."
In C, the result of a relational or logical operator has type int. There's no mixing. Unless you count the promotion of a _Bool to an int in the usual integer promotions...
Not in C.
Cute. I wouldn't recommend it, but it's perfectly clear. I haven't seen anybody advocate that sort of code, however...
Regards,
-=Dave
-- Change is inevitable, progress is not.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.