>[...]
>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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
