Comments on supposed idiocy

Examples of idiocy:
[...]
cout << b << endl; // print's 0 - why not false? You can't change it either because ostream::operator<<(bool b) is defined as a member function of ostream.

At least it is consistent. For example ...

\n enum Color {RED, GREEN, BLUE};\n cout << GREEN << endl;           // Also prints 1

However, I will agree that the decision to print 0/1 for false/true is ... surprising.

Continuing ...

bool b = true; // fine
bool b = 5; cout << b << endl; // print's 1?!?!

That's right. Bool (despite your declarations to the contrary) is not a integer type.

b = false;
cout << b++ << ' ' << b++ << ' ' << b++ << ' ' << b++ << endl;

this print's 0 1 1 1

interestingly, b-- won't compile, operator is not permitted. So if you were going to use it as a use counter bool offers surprising behavior.

Yes. This a concession to backwards compatibilty with existing code. But you know this. No one is claiming this is the correct way to define bools in a green field language.

Bottom line - bool is a quirky POS that you don't really need if you just accept that you can do your conditional branching using any convenient integer type.

This seems an odd statement. Of course you don't need it. You don't need enums either. You don't need strings. There are a lot of things you don't need.

However, bool is a common abstraction. One that programmers often provide themselves. Unfortunately, it is not possible to provide a user defined bool type in C++ that has the following behavior ...

void f(int i) { cout << "Integer version called"; }\nvoid f(bool b) { cout << "Bool version called"; }\n\nint main(int argc, char** argv) {\n  f(argc == 0);   // Prints "Bool version called"\n}

Before bool was defined as a built in type, the integer version would have been called.

So don't try to tell me that this is a good idea. Its not. It's pretentiousness at its very worst.

Wow strong language. It seems to me, given the design constraints (backwards compatibility, desire to overload on bool) the choices were far from as bad as you paint it.

It seems to me, given the design constraints (backwards compatibility, desire to overload on bool) the choices were far from as bad as you paint it.

I understand the design forces at work that lead to this mess. Incrementing a flag as a one way latch was a common idiom in a lot of older code.

What I really question is whether the increased complexity is worth it. I don't think it is. They had a choice between not having a bool and leaving the branching consitent with C, or adding a proper bool type and breaking a bunch of code.

The gutless wonderdogs did neither. This is my beef.

I dislike inconsistency and C++ has it in spades. The whole thing is a sign of muzzy headed thinking and committee dynamics.

Compare C++ to Objective C and the amateurishness of C++'s design shines like the top of the Chrysler Building.

Welcome to IWETHEY!