Why Are Both "True" and "False" Tests True

Why do both [] == true and ![] == true evaluate to false?

It's the way coercion works.

The first step of coercion is to convert any non primitive types to primitive types, then using a set of rules convert the left, right or both sides to the same type. You can find these rules here.

In your case [] == true, would pass through these 4 steps:

[] == true
[] == 1
"" == 1
0 == 1

Whereas based on operator precedence the ! in ![] == true is executed first so the expression is converted to false == true which is obviously false.

You can try the live demo by Felix Kling to better understand how the sameness operator works.

In more words:

The value ![] is false, because [] is an Object (arrays are objects) and all objects, not including null, are truthy. So any array, even if it is empty will always be a truthy, and the opposite of a truthy is always false. The easiest way to check if a value is a truthy is by using !!.

console.log("![]: " + ![]);
console.log("!![]: " + !![]);

Why are `true` and `false` both considered variables?

You’re using a book that shows clear lack of understanding of the subject matter by the author. That book is lying to you. Throw it in the trash.

true and false are Boolean literals: they are a straightforward way of writing down a value of type bool. "true" and "false" are string literals – and, unfortunately, C++ can help you shoot yourself in the foot by converting them to their address, and then to a Boolean. So you get this wonderful nugget:

bool b1 = "false"; // string contents don’t matter
assert(b1 == true);
using book = bool;
book b2 = false;
assert(b2 == false);

The asserts are a way of writing true statements in the code: they mean that, at the point they appear, the condition in the parentheses must be true.

true and false are stored in whatever way the compiler desires – this is an implementation detail and the standard places no requirements here, other than true having to convert to 1 in numerical context, and false having to convert to 0 there. Usually they are not stored as integers, but bytes (char), i.e.

assert(sizeof(int) > sizeof(bool));

Engineered bool compares equal to both true and false, why?

Found this in the C++ standard, section 3.9.1 "Fundamental types" (note the magic footnote 42):

6. Values of type bool are either true or false. 42)

42) Using a bool value in ways described by this International Standard as ‘‘undefined,’’ such as by examining the value of an uninitialized automatic variable, might cause it to behave as if it is neither true nor false.

This is not perfectly clear for me, but seems to answer the question.

Why does 1 in range(2) == True evaluate to False?

1 in range(2) == True is an operator chain, just like when you do 0 < 10 < 20

For it to be true you would need

1 in range(2)

and

range(2) == True

to be both true. The latter is false, hence the result. Adding parenthesis doesn't make an operator chaining anymore (some operators are in the parentheses), which explains (1 in range(2)) == True works.

Try:

>>> 1 in range(2) == range(2)
True

Once again, a good lesson learned about not equalling things with == True or != False which are redundant at best, and toxic at worst.

Unit test a variable for both true and false

Solution1: To access any protected attribute/method from a test
without modifying production code

You can easily modify _process even if protected, just do this:

class SubA : public A
{
public:
    void setProcess( bool val ) { process_ = val; }
};

A a;
SubA* pA = (SubA*) &a;
pA->setProcess( false );

This will work pretty well and is safe. Even if you are casting A* to SubA* which is not really valid, it will work as SubA objects in memory are the same as A objects (as SubA does not declare any extra attribute).

This only works because process_ is protected, so you create a derived class SubA and use it because compiler will allow this subclass to access the protected stuff.

Solution2: To access any protected and even private attribute/method from a test without modifying production code

Now, if process_ was private, this would not work...but, private/protected is only managed by the compiler...the attributes are here in memory and you may access them even if you are not "allowed to".

It's ugly but works perfectly:

#define protected public
#define private public
#include "A.h"
#undef private
#undef protected

{
    A a;
    a._process = false;
}

This hack makes it easy to access any private/protected attributes/functions from your test programs.

checking for both true or both false

Apologies for my initial XOR answer - I had misread your question. The correct answer is,

It is impossible in Java.

The reason is one of Boolean logic. When you have two logicals, A and B, then there are four possible states:

A  B
0  0    << A and B are false
0  1
1  0
1  1    << A and B are true

When you have a condition that says "Both A and B are true", you have just the last state. Unfortunately, the "else" (all the others) contains three possible states. You cannot have something that is true for one state, false for another, and "something else" for the other two. That's not how Boolean algebra works.

Regular expression test can't decide between true and false (JavaScript)

/g (global) regexps will do that, yes.

See this question.

When you write a literal, you're getting a new regexp object every time, so losing the lastIndex state associated with the old object.

If/ Else, test true first or false first

The only difference in both examples may be the implementation of the operator. A != operator inverses the operation result. So it adds an overhead, but very small one. The == is a straight comparison.

But depending on what you plan to do on the If/else, if there is simply assigning a value to a variable, then the conditional ternary operator (?) is faster. For complex multi value decisions, a switch/case is more flexible, but slower.

This will be faster in your case:

return (resultVar == error) ? false : true;