C# can't cast bool to int

Viewed 57049

We all know that in C# we can't cast bool to int. I wanted to see what is the binary representation of true with bitmask, but I can't use (bool & int).. I think the problem is the architecture desicion "true is true, not any number != 0" (C++) and I was wondering what the benefits of such an architecture are? What is so bad with the C true/false concept?

10 Answers

It's clearer to the programmer when an integer can't be used for true or false.

if (5 > 0) is easier to understand rather than if(5)

It's the same reason why they don't allow fall through conditions in switch statements. It's too easy to make a mistake.

In C integers are frequently doubly used as a normal number and a boolean, such as for loops that run while a certain number is not zero. That's a use which clearly has its merits for concise code, like a naïve strlen routine:

const char *s;
for (s = str; *s; ++s)
    ;
return (s - str);

but while short it masks the true purpose of that snippet, which essentially says "loop while the character I am looking at is not the null character". But written down it just says "treat it as a boolean when I feel like it, and as a number in some other cases".

This kind of double nature allegedly frequently leads to problems and it makes the code less readable (since you have to judge from the context whether a given usage of an int is intended as int or bool).

If you absolutely need to use a boolean as an integer you can either use

Convert.ToInt32(someBool)

as Noldorin mentioned or roll your own with

someBool ? 1 : 0

Both of which clearly say that you are using an int (and not a bool).

Just for information, Convert.ToInt32(fooBool) should tell you that true is represented by 1, and false by 0. (This is an arbitrary representation in the BCL, and not necessarily the one used it memory, however.)

The point here is, the bit representation really ought to be meaningless to any programmer. Booleans are meant to be used for specific purposes (i.e. flags), and shouldn't be mixed with ints, else the uses of variables can potentially become quite confusing.

I don't think the issue is some much about true/false or 1/0 as it is about the decision to make C# a strongly-typed language rather than a weakly-typed language. There are many benefits (and some drawbacks) to a language being strongly typed. One of the benefits is that it reduces bugs due to misuse (or incorrect use) of expressions.

For example,

int i = 0;
if (i = 1) {
   ...
}

won't even compile in C#, but it will both compile and execute incorrectly in C.

Choosing to make C# a strongly-typed language infers these benefits to C# programmers. Even so, they could have introduced a conversion from bool to int (and back) if they choose. I suspect that they didn't do so due to the potential for bugs like that above to be introduced.

Nobody likes all of any other entity's decisions... just write your own converter (quick-&-dirty-like)

number != 0, is too prone to error.

C# made a lot of design decisions to subvert common mistakes like this can lead to.

Related