Messages in this thread | | | Date | Thu, 20 Jul 2006 10:07:27 +0200 (MEST) | From | Jan Engelhardt <> | Subject | RE: [RFC][PATCH] A generic boolean |
| |
>[...] >from the compiler's standpoint. Function that return 'true' for an integer >type (as opposed to a C++ standard-type bool) should be tested like > > if(SomeFunction()) > >or > if(!SomeFunction()) > >instead of testing for equality > > if(SomeFunction() == TRUE) >of > if(SomeFunction() == FALSE) > >as the former (IMO) is as readable, if not more readable as the latter
Full ACK. What currently bugs me is that there are code places which "violate" your suggestion in a different way, i.e.
void *foo = null_or_not_null_that_is_the_question(); ... if(foo) do_bar();
vs
if(foo == NULL)
>, and it's likely to get optimised better.
Unlikely that it will be better, as the compiler knows that bar() returns bool, testing it against TRUE or FALSE does not make a difference to using "bar()" or "!bar()" respectively.
But I agree. The "!" operator was invented *for a reason*, so we do not need ==false.
>That and someone might give true AND return a status by returning neither >0 or 1, in which case
In that case you cannot work with bools at all, because they are not guaranteed to be big enough for status codes. Here, 'int' comes into play. And then func_return_int()==TRUE/FALSE seems strange anyhow. That's like
>> > If this is the case, then wouldn't "long" be preferable to "int"? > >Meh, it's all the same.
On x86, it is not. But x86_64 has int=4 bytes and long=8 bytes. What's wasted is probably the cacheline due to a longer immediate integer in the instruction. SPARC64 for example is even more sensitive: also has int=4 and long=8, but generates a lot more instructions for 'long' data shuffling than for 'int', because it has a small instruction size. And also start to think of 'long long' (resp. int64_t) used somewhere [in code] on x86 -- also needs extra ops because the regs are not wide enough.
Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |