Is this behaviour intended?
I'm wondering, because Visual C++ 2005 compiler issues neither an error nor a warning on this:
char test;
test = true; // assigning bool to char okay?
I know that bool is internally represented as a byte, but despite of this a warning should be issued at least.
[291 byte] By [
philkr] at [2007-11-19 19:17:07]

# 2 Re: Is this behaviour intended?
Although I know what you mean, I think there should be a warning.
In your example your assigning a number to a number variable.
In my example I assign a boolean value to a number variable. It should be obvious for the compiler that this isn't normally intended. Maybe there is some case where somebody wants to do this, but normally in cases like that the compiler also complains that a cast is required. Why not in this case?
philkr at 2007-11-10 3:04:25 >

# 3 Re: Is this behaviour intended?
Many guys tend to use chars to contain boolean values, because it has always a size==1, so it uses few memory and is more portable across shared libraries.
So, a char does not always mean a "character".
Personally, I prefer to reserve usage of char to characters.
signed char and unsigned char should be used for numbers or other values.
C++ is tolerant on loseless conversions from a fundamental type to another.
So, you can do arithmetic with two char (they are promoted to int).
But does it make sense to add two characters?
But, I am sure that there are so many programs using char as normal numbers, that it is normal not to do a warning.
It should be obvious for the compiler that this isn't normally intended.
Here is the problem. That type of thing is intended by many programmers.
I admit that ideally, if there was no backward compatibility. arithmetic could not be done with char, (but instead signed char or unsigned char). And, explicit static_cast should be needed.
But, char is not a clean character type in C++, it is more an integral type than a character type. And that should not change.
It is part of the language, and is unlikely to change in future.
You can choose to write cleanly, assigning a restrictive meaning to char, but compiler implementers can't think to any warning message that may help anybody, especially if the program construct is not dangerous. And doing arithmetic or converting boolean to char does not seem very dangerous, especially for programmers who use char as integers or boolean.
Actually, questions like : why my compiler does not do ... that optimization? ... or does not understand that I don't want that? ... or is not able to see this obvious programmatic error? are easy to answer.
The compiler implementer cannot think to all and anything.
Try to write constructs with obvious undefined behaviour... there are thousands.
Note : Many compiler vendors accept feedback and suggestions.
If you want that something is missing in a compiler, you can write an e-mail to request for a change in future implementations. :)