Why does the operator -- not exist for bool whereas it does for operator ++?

I tried in C++, and I do not know if my question apply to another language. I will be glad to know also.

I know, I can use the operator ++ with a bool. It makes any bool equal to true.

bool b = false;
// Now b == true.

Why can't we use the operator -- in an opposite way?

bool b = true;
// Now b == false;

It is not very useful, but I am curious.

  • 8
    This question on StackOverflow may be enlightening. – Blrfl Mar 1 '14 at 22:26
  • So history reason. Thank you for the link. Can you write an answer and I put it as resolved ? – aloisdg moving to codidact.com Mar 1 '14 at 23:00
  • Links alone don't make good answers, and there isn't a good mechanism for marking tnis question a duplicate of something on another SE site. – Blrfl Mar 1 '14 at 23:43
  • 1
    So we should open a topic in meta.stackexchange.com or something. I think you should get some karma for the good link and if somebody upvote you, the author from the original answer should get some karma. In fact, the original question should get some karma too. – aloisdg moving to codidact.com Mar 1 '14 at 23:46
  • 2
    @aloisdg cross site dups are a old issue on MSO. Chase the linked questions to get a fuller view of it. – user40980 Mar 2 '14 at 0:35

In the old days of C, there was no boolean type. People used the int for storing boolean data, and it worked mostly. Zero was false and everything else was true.

This meant if you took an int flag = 0; and later did flag++ the value would be true. This would work no matter what the value of flag was (unless you did it a lot, it rolled over and you got back to zero, but lets ignore that) - incrementing the flag when its value was 1 would give 2, which was still true.

Some people used this for unconditionally setting a boolean value to true. I'm not sure it ever became idiomatic, but its in some code.

This never worked for --, because if the value was anything other than 1 (which it could be), the value would still not be false. And if it was already false (0) and you did a decrement operator on it, it wouldn't remain false.

When moving code from C to C++ in the early days, it was very important that C code included in C++ was still able to work. And so in the specification for C++ (section 5.2.6 (its on page 71)) it reads:

The value obtained by applying a postfix ++ is the value that the operand had before applying the operator. [Note: the value obtained is a copy of the original value ] The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type or a pointer to a complete object type. After the result is noted, the value of the object is modified by adding 1 to it, unless the object is of type bool, in which case it is set to true. [Note: this use is deprecated, see annex D. ]

The operand of postfix -- is decremented analogously to the postfix ++ operator, except that the operand shall not be of type bool.

This is again mentioned in section 5.3.2 (for the prefix operator - 5.2.6 was on postfix)

As you can see, this is deprecated (Annex D in the document, page 709) and shouldn't be used.

But thats why. And sometimes you may see the code. But don't do it.

| improve this answer | |
  • 5
    "Some people used this for unconditionally setting a boolean value to true." Let's call them damn fools, not people. – Deduplicator Oct 7 '15 at 14:20
  • @Deduplicator: Maybe it was a matter of performance: loading a value into a variable may have taken more processor cycles than incrementing the variable. Of course, this probably does not matter on modern computers. – Giorgio Oct 7 '15 at 17:20
  • 1
    @Giorgio that is quite likely. Remember that C was written to closely match the PDP-7 instruction set and the PDP-11 had other tweaks. From this - "People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell." – user40980 Oct 7 '15 at 18:16
  • @Deduplicator: In code that uses integers for booleans, a variable that's incremented for each ... whatever ... can act both as a counter (how many times it was incremented) and as a boolean (has it been incremented at all or not). – Keith Thompson Sep 13 '16 at 23:41

To partially cope with legacy code which used int or similar as its boolean type.

| improve this answer | |

To understand the historical significance of this question, you must consider the case of the Therac-25. The Therac-25 was a medical device that delivered radiation to cancer patients. It was plagued with bad programming practices that contributed to its poor safety track record (with multiple deaths attributed to it).


(go to the bottom of page 3)

Every pass through the Set-Up Test routine increments the upper collimator position check, a shared variable called Class3. If Class3 is nonzero, there is an inconsistency and treatment should not proceed. A zero value for Class3 indicates that the relevant parameters are consistent with treatment, and the beam is not inhibited.


During machine setup, Set-Up Test will be executed several hundred times since it reschedules itself waiting for other events to occur. In the code, the Class3 variable is incremented by one in each pass through Set-Up Test. Since the Class3 variable is 1 byte, it can only contain a maximum value of 255 decimal. Thus, on every 256th pass through the Set-Up Test code, the variable overflows and has a zero value. That means that on every 256th pass through Set-Up Test, the upper collimator will not be checked and an upper collimator fault will not be detected. The overexposure occurred when the operator hit the "set" button at the precise moment that Class3 rolled over to zero. Thus Chkcol was not executed, and F$mal was not set to indicate the upper collimator was still in field-light position. The software turned on the full 25 MeV without the target in place and without scanning. A highly concentrated electron beam resulted, which was scattered and deflected by the stainless steel mirror that was in the path.

The Therac-25 used something like the equivalent of operator++ on a bool. However, the programming language they used was not C++, and their data type was not bool. Unlike the guarantee in C++, however, a regular integer type simply keeps going up. Their data type was the equivalent of uint8_t.

C++ decided to keep the operator++ around for people used to programming like this, but instead of incrementing the value, it simply sets it to true to prevent things like this.

Note that operator++(bool) is deprecated.


Annex D of C++14:

D.1 Increment operator with bool operand
The use of an operand of type bool with the ++ operator is deprecated (see 5.3.2 and 5.2.6).

| improve this answer | |
  • While that would explain why its deprecated, it doesn't explain why it exists in the first place. – user40980 Mar 15 '14 at 18:23
  • It exists because there were some people who set a boolean value by incrementing it when programming in C. C++ was designed to ease the transition from C, so they supported it with the bool type. I was just trying to give a historical example of when people actually programmed this way. – David Stone Mar 15 '14 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.