139

Can I assume (bool)true == (int)1 for any C++ compiler ?

chema989
  • 3,962
  • 2
  • 20
  • 33
Petruza
  • 11,744
  • 25
  • 84
  • 136
  • 3
    The casts in your question are redundant, should they be reversed? – GManNickG Apr 27 '10 at 21:06
  • 12
    He doesn't mean them to be casts, he means `bool t = true; int n = 1; if (t == n) {...} ;` – egrunin Apr 27 '10 at 21:07
  • 7
    @egrunin: Eh, but true is a bool and 1 is an int anyway. :) – GManNickG Apr 27 '10 at 21:19
  • 1
    Right, I meant to state the type of the values. – Petruza Apr 28 '10 at 13:15
  • IMHO it doesn't mean, that everything NOT 1 is false. int *ptr = new int[10]; if (ptr) //new succeeded so address is different from zero which is false and NONZERO is TRUE – relascope May 26 '15 at 20:48
  • 3
    `(int) true` is `1` as an integer value, but something as `if (pointer)` goes through the then part if `pointer != 0`. The only thing you can assume as true is that `false == 0`, and `true != 0` (and `true` evaluates to `1` when cast to `int`) – Luis Colorado Sep 21 '16 at 11:38

5 Answers5

160

Yes. The casts are redundant. In your expression:

true == 1

Integral promotion applies and the bool value will be promoted to an int and this promotion must yield 1.

Reference: 4.7 [conv.integral] / 4: If the source type is bool... true is converted to one.

Joe
  • 41,484
  • 20
  • 104
  • 125
CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • This is true only for primitives. Beware of value of true coming from imports from other libraries. – Joshua Apr 27 '10 at 21:01
  • 1
    @GMan: Thanks for the vote of confidence. If a compiler promotes `true` to any other integer value then it's not a conforming C++ compiler. – CB Bailey Apr 27 '10 at 21:03
  • 9
    @Joshua: `true` is a keyword defined by the language. It can not be redefined by a library. `#define`s are not allowed to redefine keywords. – jalf Apr 27 '10 at 21:04
  • @Joshua - it's part of the language, so no library should be defining values for `true`. if you know of one that does it, please let us know so we can avoid it. :-) just like we would avoid any library that defines `while`. – Franci Penov Apr 27 '10 at 21:06
  • 26
    @jalf: #define's are indeed allowed to define system keywords. The pre-processing phase of C compilation is purely textual, and knows nothing of keywords or C syntax in general. Nevertheless, it is, of course, almost always a bad idea to redefine language keywords. – Dale Hagglund Apr 27 '10 at 21:07
  • 2
    @jalf. They're not? See http://gcc.gnu.org/onlinedocs/cpp/Macros.html, and at least one of the entries in the International Obfuscated C Code Contest, which once asked "When does a `while` not take a while?" (Answer: when it takes two parameters, because then that entry had `#defined` it to `printf`.) – Ken Bloom Apr 27 '10 at 21:08
  • @Ken Bloom: The rules may be different between C++ and C. – David Thornley Apr 27 '10 at 21:14
  • 1
    I think that that it's quite safe to say that no compiler or library implementing the standard will redefine any keywords with macros because that would make it so that when any user of them used them, they would be in violation of the standard. So, in effect, they're guaranteed by the standard. However, there's nothing to stop you or a third party library from being stupid and redefining them. – Jonathan M Davis Apr 27 '10 at 21:23
  • 1
    @Joshua: `true` is a C++ keyword, and may not be used for any other purpose. 17.4.3.1.1 in the Standard forbids `#define true ...`, so no conforming program can have `true` mean anything other than the primitive `bool` value. – David Thornley Apr 27 '10 at 21:25
  • 3
    C99, §6.10.1/1 says: "The expression that controls conditional inclusion shall be an integer constant expression except that: it shall not contain a cast; identifiers (including those lexically identical to keywords) are interpreted as described below;" Though not stated as direct permission, this clearly contemplates the possibility of a macro that's "lexically identical" to a keyword. – Jerry Coffin Apr 27 '10 at 21:29
  • 1
    @David Thornley: that's almost but not quite true. A translation unit is only prohibited from re-defining key words if it includes a header. A translation unit that was entirely self-contained (didn't depend on any headers) could apparently re-define keywords; whether it should or not is a separate question... – Jerry Coffin Apr 27 '10 at 21:33
  • @David Thornley: If I'm reading that right, apparently it's OK to redefine `true` as long as you don't include a header. – dreamlax Apr 27 '10 at 21:34
  • If that is true, then headers can obviously not do `#define TRUE 9`. And if a self contained file defines a function that returns a `bool`, and that unit used the preprocessor to change `true` to `9`, then the compiler will simply convert that `9` back to `true` in the return statement. So there is still no way for `true` and `false` to be anything other than what they are unless you personally change them. – Dennis Zickefoose Apr 27 '10 at 21:50
  • What I meant was do not assume that a function in a third party library declared in a header file to return bool returns a true that cast as integer returns 1. – Joshua Apr 27 '10 at 22:47
  • 3
    Oh, and #defines are allowed to redefine keywords. C++1x caused too many problems with its new keywords so that requirement had to be removed. – Joshua Apr 27 '10 at 22:49
  • The standard allows the C++ preprocessor to have the ability to redefine keywords, but programs that do so are not necessarily standards compliant. – Ken Bloom Apr 28 '10 at 00:57
  • Ken opened a new question for the discussion here: http://stackoverflow.com/questions/2726204/c-preprocessor-define-ing-a-keyword-is-it-standards-conforming – Georg Fritzsche Apr 28 '10 at 01:07
  • Well, in case someone wants to use my library and re-defines true as something else than 1, it's their problem, not mine. :D – Petruza Apr 28 '10 at 13:23
  • @Jerry: Thanks. I apparently read that too fast. Is there anything actually forbidding redefinition of keywords in general? Why would the ban apply only to translation units without headers? – David Thornley Apr 28 '10 at 13:38
  • @Joshua: Why not? *`true` always converts to `1`.* It doesn't matter if someone had originally done `(bool)5` to get that `true`: `(int)(bool)5` is `1`. – Lightness Races in Orbit Dec 14 '11 at 15:20
  • Trust me, don't assume it when crossing library boundaries. I've seen too many cases where a type bool casted back to char had some other value than 0 or 1. This also causes trues to compare unequally. && and || work correctly. – Joshua Dec 14 '11 at 19:39
  • 1
    @Joshua: You should complain to your compiler vendor. No currently maintained compilers that I know of still get this wrong. – CB Bailey Dec 14 '11 at 22:16
  • The compiler's *not* the problem. – Joshua Dec 14 '11 at 23:04
19

Charles Bailey's answer is correct. The exact wording from the C++ standard is (§4.7/4): "If the source type is bool, the value false is converted to zero and the value true is converted to one."

Edit: I see he's added the reference as well -- I'll delete this shortly, if I don't get distracted and forget...

Edit2: Then again, it is probably worth noting that while the Boolean values themselves always convert to zero or one, a number of functions (especially from the C standard library) return values that are "basically Boolean", but represented as ints that are normally only required to be zero to indicate false or non-zero to indicate true. For example, the is* functions in <ctype.h> only require zero or non-zero, not necessarily zero or one.

If you cast that to bool, zero will convert to false, and non-zero to true (as you'd expect).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
11

According to the standard, you should be safe with that assumption. The C++ bool type has two values - true and false with corresponding values 1 and 0.

The thing to watch about for is mixing bool expressions and variables with BOOL expression and variables. The latter is defined as FALSE = 0 and TRUE != FALSE, which quite often in practice means that any value different from 0 is considered TRUE.

A lot of modern compilers will actually issue a warning for any code that implicitly tries to cast from BOOL to bool if the BOOL value is different than 0 or 1.

Franci Penov
  • 74,861
  • 18
  • 132
  • 169
6

I've found different compilers return different results on true. I've also found that one is almost always better off comparing a bool to a bool instead of an int. Those ints tend to change value over time as your program evolves and if you assume true as 1, you can get bitten by an unrelated change elsewhere in your code.

Michael Dorgan
  • 12,453
  • 3
  • 31
  • 61
  • 4
    This is an incorrect answer for C++, as `true` is a language keyword with defined behavior. If you refer to a commonly defined macro such as `TRUE`, it is correct. – David Thornley Apr 28 '10 at 13:48
  • 1
    Could be my experience was with C compilers - I've spent plenty of time with them over the years. My point about directly using mathetical expressions in if statements stands though. We had code that seeing if a bit shift was non zero in an if, then someone else took that same non-zero value and assumed it was 1 and blew stuff up. A simple conversion to true/1 would have prevented that. – Michael Dorgan Apr 28 '10 at 14:46
  • I too have seen behavior of this kind. Admittedly, the last time I saw it was about 1999. I was using GCC. The language was C. Still, I have indeed seen such behavior. – thb Nov 15 '14 at 12:17
  • 1
    This happens because `bool` is stored in 1 byte, not 1 bit. In a valid program that byte can only ever hold the values 0 or 1, but in the presence of **[undefined behavior](https://stackoverflow.com/questions/56369080/setting-extra-bits-in-a-bool-makes-it-true-and-false-at-the-same-time)** it's quite possible to get a value other than 0 or 1 stored in that byte. The compiler does not compensate for this situation, which can lead to the experience described in this answer. – rustyx Sep 11 '21 at 13:11
1

If I write the code:

int a=true;
cout<<a;

The output will be:

1

So yes, you can assume (bool)true==(int)1

Rafael Tavares
  • 5,678
  • 4
  • 32
  • 48
Anwesha Roy
  • 11
  • 1