Pointers and Booleans

Started by
11 comments, last by TheUnbeliever 12 years ago

If true was defined on a language level or by the compiler to be any non-zero value stored in the physical bool-variable in memory, then it would also be the language's or compiler's responsibility to perform the correct comparison. Thus, if true is a non-zero value and two trues are required to compare equal, then it would be the compiler's responsibility,not the user's, to implement the == operator correctly.
[/quote]
I agree with the underlying intent of your post (I believe), but not quite with the detail. As I see it, the compiler has (at least) two choices, either of which will make boolean comparisons behave reasonably. Either do any extra work during any comparison involving a bool, or do any extra work when a boolean value is "created" - assigned from an expression that is not already a "safe" bool. From the programmer's perspective, unless they break the type system then these two approaches should be identical.

Obviously, messing with type punning or unions could create situations where the program loads a (potentially arbitrary) value into space that will be later treated as a boolean. Most such code is, to my knowledge, undefined behaviour (at least I cannot think of a counter example on the spot).

Doing both is possible and would be the "safest" approach, making it both easy to debug the code (you'll only see values of 1 and 0 in booleans) and would also handle people accidentally breaking the type system (is there any complex C++ program that doesn't depend on undefined behaviour). Such a compiler implementation would be inconsistent with the goals of most C++ code, which emphasises speed over safety.


Thus, if true is a non-zero value and two trues are required to compare equal...
[/quote]
To come back to this point, this is an interesting statement. I'm not a C++ guru that can quote standards. I'm not sure that but as a more general question in language design it is interesting what the following program should print:

i = 42
b = true
if b == i
print "#{b} == #{i}"
else
print "#{b} != #{i}"
end

I'm not sure I like the above program to print that 42 is equal to true, without forcing me to be more explicit about why I am comparing these values. It is almost as likely to be a mistake as it is to be what I intended.

I certainly appreciate the convenience of C++'s conversion-to-bool in conditional context, particularly for pointers. I find languages that force you to write if(x != null) more verbose than languages that allow if(x) instead.
Advertisement

Well if the language doesn't support casting a byte/int/etc.. to a bool, you can always go ghetto:
1. allocate a byte (or whatever the size of a boolean in memory is on the target hardware).
2. write the integer "42" in it.
3. copy that memory into a boolean variable of your choice.
4. blink.png
Check it out:
<code removed>


Well I saw a little flaw in your code, you check only whether boolean is true OR something else, so I made little test of my own:

bool b1 = true, b2 = false, b3; // 3 bools, true, false and hack
char a1, a2, a3 = 2; //  3 chars, to store true, false and hack
memcpy(&a1, &b1, sizeof(bool)); // copying 'true' into char to see it's value in number
memcpy(&a2, &b2, sizeof(bool)); // copying 'false' into char to see it's value in number
memcpy(&b3, &a3, sizeof(bool)); // copying number 2 into bool
cout << (int)a1 << " (value of bool == true)" << endl; // typecasting to int to avoid weird symbols
cout << (int)a2 << " (value of bool == false)" << endl; // typecasting to int to avoid weird symbols
cout << b3 << " (value of bool == 2)" << endl; // no typecast, we need bool value
if(b3 == true)
  cout << "1 (bool == true)" << endl;
else if(b3 == false)
  cout << "2 (bool == false)" << endl;
else
  cout << "3 (bool is something else)" << endl;


Can you guess what it prints? Well here's the answer:
[spoiler]1 (value of bool == true)
0 (value of bool == false)
2 (value of bool == 2)
3 (bool is something else)
[/spoiler]
It's kind of fun messing around with some aspects of a language which aren't well-documented.


If some aspect of the language is unspecified, no behaviour of any particular implementation is part of that language.
[TheUnbeliever]

This topic is closed to new replies.

Advertisement