# Thread: More efficient way to structure this function?

1. ## More efficient way to structure this function?

I have the very basic function below:

Code:
```int isEven(int x){
return ((x%2) == 0) ? 1 : 0;
}```
I was recommended to use something related to booleans to further improve this function, should I really look into that? It seems as if using booleans would give no advantage at all with this (besides quicker checking without having to compare the results with ==).

Is there any way this code could be "cleaner"?

2. Originally Posted by Justin H
I have the very basic function below:

Code:
```int isEven(int x){
return ((x%2) == 0) ? 1 : 0;
}```
I was recommended to use something related to booleans to further improve this function, should I really look into that? It seems as if using booleans would give no advantage at all with this (besides quicker checking without having to compare the results with ==).

Is there any way this code could be "cleaner"?
Code:
```int
isEven(int x)
{
return (1 & (x^1));
}```
OR
Code:
```int
isEven(int x)
{
return (!(x&1));
}```

3. Yes, there is :

Code:
```int isEven(int x){
return !(x%2);
}```

I hope that I have helped .

4. It would be cleaner without the Ternary operator.

I suggest looking up Boolean not operator.

Edit: I am too slow today.

Tim S.

5. Originally Posted by rjjj
Yes, there is :

Code:
```int isEven(int x){
return !(x%2);
}```

I hope that I have helped .
Code:
`printf("3 %c", (isEven(4)) ? 'Y' : 'N');`
I'm using that to test the function:

Code:
```int isEven(int x){
return  !(x%2);
}```
Why does it say 3 (prints out the char Y) is even?

6. Um, reality check:

printf("3 %c", (isEven(4)) ? 'Y' : 'N');

The argument is 4, so the function is actually working.

7. Originally Posted by whiteflags
Um, reality check:

printf("3 %c", (isEven(4)) ? 'Y' : 'N');

The argument is 4, so the function is actually working.
Woops...

8. Originally Posted by Justin H
I was recommended to use something related to booleans to further improve this function, should I really look into that? It seems as if using booleans would give no advantage at all with this (besides quicker checking without having to compare the results with ==).
In C, zero values are false, non-zero values are true. The result of the operator == is either 0 or 1. Trying to do micro optimisations at this level tends to be silly with today's optimising compilers. I would suggest for clarity:
Code:
```int isEven(int x) {
return x % 2 == 0;
}```
Using !(x % 2) works here too, but then conceptually the result of x % 2 is an integral, not boolean, value (even though it is of type int either way). Alternatively:
Code:
```int isEven(int x) {
return x & 1 == 0;
}```
but an optimising compiler is likely to optimise the modulo version if it is slower, and so it is a question of whether you think the modulo version is more readable or the bitwise and version is more readable (to experienced programmers I daresay both are fine).

If this is somehow a real performance bottleneck (I have a feeling it isn't), then you should check to see if you can get the compiler to inline this function, or else turn it into a macro (but beware the pitfalls of macros), e.g.,
Code:
`#define IS_EVEN(x) ((x) % 2 == 0)`
Oh, and of course remember to test that the change really is an improvement.

9. Originally Posted by laserlight
If this is somehow a real performance bottleneck (I have a feeling it isn't), then you should check to see if you can get the compiler to inline this function
If I may interject, that would be just
Code:
```static inline int isEven(const int x)
{
return ((x % 2) == 0);
}```
The static keyword makes the function only visible only in the current compilation unit (the current file, or current files if this is in a header file included by a source file). The actual point, however, is that most older C, and all C99 and C++ compilers, treat static inline functions as efficiently as macros.

(In case you wonder, the parentheses are just my style.)

C99 compilers (if using gcc, use the -std=c99 option) provide a true boolean type, _Bool. The equality operator == does yield an int (1 if equal, 0 otherwise), but you can just cast it to the boolean type. In C99, you can write the inline function thus:
Code:
```static inline _Bool isEven(const int x)
{
return (_Bool)((x % 2) == 0);
}```
I would personally omit the cast, because the compiler will do it for you, and it does not make the code any easier to read.

Should you do the above?

In my opinion, static inline is portable and very useful, and does work -- in the cases I tested, they were just as fast as macros. Writing a function is certainly easier than writing a macro, if you need anything more complex than one simple expression -- and because of that, my more complicated inline functions were sometimes faster than the macros I came up with.

However, with more complex functions, you may be fighting yourself: because of CPU architecture details, the overall code might be faster when the code is not inlined; this is typical when the inlined code is long, but rarely executed. So, leave the optimization for the last step. You can mark the functions just static, and when the program is near ready, consider if the most often used helpers should be static inline or not.

(For simple accessor functions (set/get value in a multidimensional array), I often have a macro without any error checking, and an inline function with bounds checking. I then use the macro everywhere I know I am within the bounds, and the inline functions where I think I might go over the bounds.)

I write C99 almost exclusively, but I practically never use the _Bool type. I don't know exactly why. I suspect it is because usually my functions return zero for success, and an error code otherwise (usually reusing the errno constants). I guess I rarely use pure boolean return values for my functions.

Of course, if you don't want to be limited to C99 and C11, you should not rely on _Bool anyway.