but it DOES work this way, because every C compiler fulfills the algebraic sentences of logic.
(not (1==2)) = true
(not (2==2)) = false

Actually true and false are 2 possible values of a binary digit.
But C doesn't store boolean values in bits, but in byte or word variables.
And thats why even if always false=0 => true = (!0) = anything but 0.

The trouble begins if you set sth like
#define true 1

if you did, it's bullshit.

Give me a single example of a C compiler that doesn't do that. In your logic they are all bullshit.

there is no value "true" or "false" in ANSI C, so the problem doesn't exist here.

But if other compilers did it the same way as it's implemented in RobotC: yes, then it's bullshit, too,
because it breaks the algebraic rules.

There's no equality in injustice.

I think if you had actually checked the ANSI C standard, you'll find that it doesn't define a "bool" type at all! You need to get to C++.

You will find that most C compiles include the file "stdbool.h" in their library distribution. And you'll usually find that somewhere in this file declarations similar to the following.

It is pointless to continue this discussion. ROBOTC is what it is on 'bool' types. It is one of the useful extensions to the language implemented in ROBOTC. And this type of extension is found in many other much higher cost C compilers (Microsoft, IAR, Renesas, Microchip, Atmel, ...) -- either as a C extension or via "stdbool.h".

That is exactly my point. Although ANSI C doesn't define "true" and "false" at the language level, most compilers include #define, const or enum declarations called "true" and "false" for the conviencence of programmers. They are useful for making code more readable such as the difference between:


and



If you look at my earliest post on this topic, my recommendation was to avoid using "true" and "false" as operands with relational operators "== true", "== false", etc. Since the other operand is already a boolean expression the relational operator is unnecessary and leads to exactly this kind of confusion. The "true" and "false" constants should only be used as r-values in assignment statements "x = true" and as parameters to functions that take boolean arguments "x(false)".

If ANSI C did define "true" and "false" as language keywords then the behaivor you are asking for would make sense. Since the language (and therefore the compiler) does not believe that there is anything special about the words "true" and "false", it can't contextually change the meaning of "==" as you suggest.

Note: There are non-C languages that intrinsicly support "true" and "false" as keywords and do not have these kinds of issues. Unfortunately none of them will generate code for the NXT.

Jeff

I think you guys should just stop arguing about who is right, and look at this as a lesson on what to watch out for in "C" programming in the real world.

I have been programming in "C" for 30 years (yes, since 1978), and I never make any assumptions on what TRUE and FALSE are defined as. I always test for FALSE and NOT FALSE instead of testing for TRUE since in my experience, different compilers do indeed define TRUE as different values.

Just test for FALSE or do your own #define to redefine what you think TRUE and FALSE should be.

Paul Tan.

I'm completely with you, that's all the same that I ever said.


Regarding this, you can't go and define a "faked constant" also called "true", which always is only equal to 1.

That's a contradiction.

But maybe you can do it this way:


With this work-around, the "if-terms"
if (expression)
and
if (expression==true)
after all will become equivalent to each other

And so let's close this discussion.