Did you know this was valid C++

#include <iostream>
using std::cout;
using std::endl;

int main ()
{
  bool b = false;
  cout << b << endl;
  b++;
  cout << b << endl;
  b++;
  cout << b << endl;
  return 0;
}

You can call increment on false to get true, and increment on true to get ... true.
And if you replace ++ with -- , that's not valid C++.

I only found this out just today; it's been slated to be deprecated in C++17 (link) Enjoy while you can!

WHAT? I thought for sure (bool)++ was negate. This is like Javascript-level stupidity.

Is that compiler dependent?

[edit] Also, side note: Lots of people I know are surprised that you can multiply strings in some (read: good) languages. It just means repeat. Which is insanely useful when you need to do something like:

print "text header\n" + "-"*80 + "\n"

As well as other formatting I can't recall off the top my head. I love learning about stuff like that where you go "Where has this been all my life?"

Is b++ just the same as b = true? Anyone tested it or looked at the assembly?

By the way, negation would be b ^= 1. Unless C++ disallows it, of course

With the postfix operators you have to increment and print them in two different statements, otherwise you get the original value

But it looks like bools are limited to be either 0 or 1. I guess b + 1 would be 1?

By the way, what compiler version did you use?

What possible reason would you have to increment a bool anyway? Either set it to true or false, anything else is madness. Using ischar() as a number base makes about as much sense.

Well, looking at it from C it makes sense - there bool is the same as int and anything except zero means true. So if x is 1 and you do x++ it gets 2, which is still true.

It is stupid that they allowed ++ for bool in C++, but so are 1000 other things in C++, so I don't see anything special here

I forgot to mention I'm running GCC. I don't recall the version, it's in the newer (maybe experimental?) branch which is necessary for proper c++14 (or whatever) support. I don't recall which, it's been a long time since I had to install it.

Why not x-- then?

As it is, you can flip false to true, or true to true, but not true to false. I would think the operators should be symmetrical, or not at all.

But why would you do that with a bool, as opposed to some sort of stack pointer or ring buffer? Not to mention the wraparound, which is admittedly huge.

I used MSVC, clang and gcc (not sure of the latest versions but all recent)

I suppose if you view bool as a one-bit arithmetic type then incrementing true is an overflow and that results in undefined behaviour - so the value could be anything.

And I suppose if you incremented something N times and decremented it N times you might expect to be back where you started, which can't be guaranteed for bool so they disabled '--'.

Maybe there was some reason for it back when they wrote the spec and maybe it just slipped through the net?

[edit] The fact that it's post increment gives it one possible use, though it's not hard to find alternatives:

void printlist(int n) {
 bool comma = false;
 for (int i = 0; i < n; ++i) {
  if (comma++) {
   cout << ',';
  }
  cout << i;
 }
}

The original example was here using C++ ranged for statement which makes a bit more sense.

I really don't understand why they added a separate function for just that use case, though...

I'm of the opinion that if a sensible meaning can be defined for an operator then it should be. I like being able to make code terse and operators are the best way to achieve that from the language or a global library. I don't see this as a problem at all, as long as the results are defined. If anything, it's a WTF to me that you cannot decrement. It's no surprise to most of us that a boolean type is typically represented by a 0/^0/!0 byte or bit. And we all understand what the result would be of incrementing those. It may not entirely make sense logically, but at the same time a useful meaning can be applied to and derived from it.

But we have tons of defined overflow scenarios. Unsigned overflows, signed overflows, float overflows. It seems strange they would just leave that one alone.

My opinion--and it's about as valuable as that--is that the more things that "don't immediately make sense" the more a programmer has to keep in his mind at all times while programming. And the more balls a programmer has to juggle at once, the more likely you hit create an error.

I'm sure there's some brain function / sign-of-intelligence that corresponds to how many ideas a person can have in their brain at one time. And the more taken up by the programming language, the less available for comprehending the task at hand. Which is why many people solve complex problems outside of code... by solving the problem separated from implementing that problem, you free up some "slots" in your brain to help take a "too big to fit" problem and hopefully fit it.

Actually, have you tested for an error in that code? What happens if you increment a bool 65536 times? Does it eventually wrap a 8/16/32/64-bit integer around to zero?

I compiled this as C++ in VS 2015, no optimizations:

void incbool(bool b)
{
  b++;
}

And got this:

?incbool@@YAX_N@Z (void __cdecl incbool(bool)):
  00000000: 55                 push        ebp
  00000001: 8B EC              mov         ebp,esp
  00000003: 51                 push        ecx
  00000004: 8A 45 08           mov         al,byte ptr [ebp+8]
  00000007: 88 45 FF           mov         byte ptr [ebp-1],al
  0000000A: C6 45 08 01        mov         byte ptr [ebp+8],1
  0000000E: 8B E5              mov         esp,ebp
  00000010: 5D                 pop         ebp
  00000011: C3                 ret

It's just copied, and then set to true.

All 4 of gcc, clang, g++, clang++ produce the same asm output for C/C++ code (simply moving the value 1 into the variable). So actually C's ++ operator behaves the same on a bool as C++'s.

Yeah, I get get same result in VS 2015. Only the name mangling of the function changes, the assembly is otherwise identical. I guess VS finally supports C99 bool, then.

And this, boys and girls, is why you should never use bitwise operators when you should use logical operators.

Case in point:

Here, if bools are treated like ints, the two if()s will behave differently. However, you could create a StrictBool class that behaves like a bool should. All operators will be overloaded with versions that use C++'s 'explicit' keyword with StrictBool-paramaters to prevent implicit casting, and there will be non-explicit versions of the operators that for each paramater, regardless of it's type, do something like value = (paramater?true:false) . In this case, both if()'s in the above code will be equivalent if the functions return StrictBools.

Yeah

{"name":"636x460design_01.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/8\/48bed991ae72aac26032315a4ba6c62b.jpg","w":636,"h":460,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/8\/48bed991ae72aac26032315a4ba6c62b"}

I ran some rudimentary (uncomprehensive) tests for performance between either several bool types or bitwise on an int.

Bitwise was a bit slower.

...

You should be careful with that kind of thing. Many simple operations require only one cycle on the CPU to do. And if you are comparing ints to bools on a PC (32 or 64 bits), you are probably comparing 32-bit types to 8-bit types. Which one is faster depends on what you do with. You could be comparing an operation to one that's different in either implementation, purpose, or both. Just saying

Isn't it the case that the compiler ensures that bools always have a 0 or a 1 stored in their memory location?

I think Visual Studio warns if an int is implicitly cast to bool, and the wording of the warning suggests that there will be a performance hit from the operation of constraining its value.

Since ++ just copies it and sets it to true, then there's no reason not to include -- to copy and set to false.

Note: my actual position is that the operators should not be used at all on bool.

All of that's probably true

It doesn't even need to copy, just set.

It has to copy, that's the whole point of postincrement.

Fuck Matthew Leverton, just fuck him.

Write out your truth table and all possible outcomes (4 of them).

Bad thread ?

Arthur, the operator needs to return the old value of the variable from before it was set to true. For example:

bool munge(bool &x) {
    return x++;
}

That function will set x, but it will also return x's old value. To do that, it has to copy it.

Granted the compiler could optimise that away if the x++ appears as a statement with its value unused.

Now, if x is some large class with an overloaded '++' operator, ++x and x++ can make all the difference, as copying would take longer.

{"name":"609921","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/a\/8a20a909009bfcd5bfee645bece22df7.png","w":474,"h":474,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/a\/8a20a909009bfcd5bfee645bece22df7"}