Take the 2-minute tour ×

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?

share|improve this question
add comment

8 Answers

up vote 13 down vote accepted

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.

share|improve this answer
I actually dislike the way they do fall through with switch statements in C# a LOT. There are a lot of cases where fall through is very useful to have. –  Joseph Jun 3 '09 at 19:51
@Joseph: The case that's the least error-prone is still allowed - you can fall through provided you don't do any work first. But having a case fall through after doing other "work" is not easily maintainable. –  Reed Copsey Jun 3 '09 at 19:57
@Joseph: that it is useful does not mean that it's not error prone, or not easy to make mistakes with. –  Fredrik Mörk Jun 3 '09 at 19:58
@Fredrik & Reed I understand, I just don't think it's very error prone, but I guess that's just my (uncommon) opinion. I've never had a difficulty understanding the switch statement construct in the C++ sense, but I guess I can see why others might find it conceptually easier the C# way. –  Joseph Jun 3 '09 at 22:23
@Joseph I don't think it's understanding how it works is the problem they were preventing. I think they are just trying to stop people from making typos, mainly forgetting to put the break statement at the end of a case. I do agree with you there are scenarios where it would be helpful and at times a little frustrating that I can't use it,but I bet not being able to do has saved me more times than not. –  Kevin Jun 4 '09 at 11:04
show 3 more comments

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


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).

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
this has nothing to do to "strong-typeness". the if (i=1) it's possible in C because the assignment operator return a value (useful if you want to do a = b = c = 5) for example, Python is strongly typed AND the assignment it's a statement, and doesn't "return" nothing. So doing something like "if a = 3:" it's an error. But python itself has a rule saying "anything has a boolean interpretation": empty collectios, 0, the empty string are False, anything else True, so you can do mylist = [] if mylist: something –  ZeD Jun 3 '09 at 20:12
Yes, but the reason that it allows the result of the assignment to be used in this context is because it is weakly-typed. Almost certainly the intent is i == 1, which is a boolean result and in C# would be allowed in that context. If C were strongly-typed the result of the assignment would be disallowed in this context, as it is in C#. As it is, the result of the assignment is (erroneously, in this case) casually evaluated as boolean and thus a bug is born. –  tvanfosson Jun 3 '09 at 21:36
add comment

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

share|improve this answer
add comment

You make a good point on these. However it does remove one shortcut.

With c, toggles can be easily done by the code "bBool = 1 - bBool".

If bBool is true (1), then 1 - 1 = 0. bBool changes to false.

If bBool is false (0), then 1 - 0 = 1. bBool changes to true.

Instead in C# I'm required to do a conditional to check the state, and then set it to it's opposite, which causes more work for the machine and me.

share|improve this answer
Am I missing something? bBool = !bBool; does what you describe, no? –  MarqueIV Jul 11 '11 at 11:29
add comment

number != 0, is too prone to error.

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

share|improve this answer
Not sure what your point is. Maybe you could elaborate a bit more. –  jpierson Oct 13 '10 at 21:36
By not allowing things like <code>if (27)</code> the language forces people towards a syntax that is more reliable like: <code>if (27 > 0)</code> –  Peter Drier Sep 1 '11 at 15:28
Ah, I see now that "number 1= 0" is a direct snippet from the original post. Perhaps putting a bit more context in your answer will help readers understand your point. In it's current form it doesn't make sense by itself. In general it is best to have some form of the original question within your answer, it doesn't need to be a direct quote but instead a rephrasing of the original question. –  jpierson Sep 22 '11 at 13:33
add comment

int n = (bBool) ? 1 : 0

share|improve this answer
This is not a cast –  Svetlozar Angelov Aug 24 '09 at 9:35
I ALMOST have to down vote you for the use of Hungarian notation, yuk! –  jpierson Oct 13 '10 at 21:37
add comment

Your Answer


