/*
Description: This function saturate input 32 bit number into a 16 bit number.
If input number is greater than 0x7fff then output is saturated to 0x7fff.
else if input number is less than 0xffff8000 then output is saturated to 0xffff8000
else output is same as input.
*/
int16 qm_sat32(int32 op)
{
int16 result;
if (op > (int32) 0x7fff) {
result = 0x7fff;
} else if (op < (int32) 0xffff8000) {
result = (int16) (0x8000);
} else {
result = (int16) op;
}
return result;
}
/*
Description: This function saturate input 32 bit number into a 16 bit number.
If input number is greater than 0x7fff then output is saturated to 0x7fff.
else if input number is less than 0xffff8000 then output is saturated to 0xffff8000
else output is same as input.
*/
int16 qm_sat32(int32 op) {
return (op > (int32) 0x7fff) ? 0x7fff : (op < (int32) 0xffff8000) ? (int16) (0x8000) : (int16) op;
}
>>8 The first form is easier to read and the object code will be the same in both cases.
The object code will be the same for both if your compiler is smart. Do you really need variable assigning? As for readability, I will answer this as soon as I stop laughing.
>>9
Code is for programmers to read and only incidentally for computers to execute. >>1 is written in C rather than assembly for the sake of the programmer. >>2 doesn't take much effort to read, but I would that most programmers that have a stake in reading the driver code would have require a larger cognitive effort to comprehend it.
The optimized code of >>1 and >>2 will be the same.
Name:
Anonymous2010-09-11 13:31
The ternary operator ultimately ends up being pretty useless. It's always the case when using the ternary operator that you lose readability for the sake of reducing the number of lines written, while gaining sometimes literally nothing in terms of efficiency and certainly not clarity. It's one of those nice programming ideas that ends up not being very useful in practice. It seems more suitable for functional programming languages than for imperative languages like C.
>>13
Better to just get rid of statements and have everything be expressions, including conditionals, which isn't necessarily tied to functional programming.
Name:
Anonymous2010-09-11 18:36
>>13 It's always the case when using the ternary operator that you lose readability
Only if you habitually underuse it. Once you get over the surprise of seeing it, the ternary operator nearly always provides a net readability gain by reducing the number of obfuscatory temporary variables needed.
>>35
You're stupid for using a macro in an unsafe way.
The fact that you're stupid enough to insert a chainsaw into your anus doesn't mean that everyone who uses a chainsaw is stupid.
>>38
The problem is, >>33 might not have know it was a macro. Perhaps he was just told in the documentation that it is a thing that clamps its first argument to between its second and third arguments. He then does CLAMP(x++, y++, z++);. Is this his fault?
>>39
That's why it is in UPPERCASE. Generally, uppercase is used for macros, and especially ones that might re-evaluate their arguments.
Someone who is too dumb to use these sorts of tools should stay away from them. That doesn't mean that they're bad.
>>40 is a tremendously stupid implementation and assumes that x2, low2, and high2 aren't already names in use elsewhere in the code. With -Wshadow (which, btw, can be a tremendous help in tracking down otherwise highly obscure problems sometimes) such code would have to unnecessarily be rewritten. Don't be hostile to your users for the sake of idiots' safety. That's what Java is for, not C.
Name:
Anonymous2010-09-13 19:40
>>42
Agreed. As a general rule I use uppercase only for badly behaved macros (either they evaluate their arguments multiple times, or they open a block and cannot be used in an expression, or something else funny.) If a macro behaves like a function, then you won't need to know it's not a function, so there is no reason it can't be named like a function.
If >>40 enclosed the block in parens (making it a statement expr) and used typeof it would actually work in GCC, Clang, and a few others. I'd rather have portability though.
In any case clamp() is a completely retarded and brain-dead example because there is no reason it shouldn't just be a function.
Name:
Anonymous2010-09-13 20:16
>>43
You can't take the address of macros. It's better to just follow the uppercase convention for all macros, unless you're specifically trying to replicate some other function with a macro (e.g. C standard library)
>>41
typeof is nonstandard, as is anything that would allow a code block to evaluate to a value.
Name:
Anonymous2010-09-13 21:47
>>44
Actually I'd argue that it's better to not expect to be able to take the address of any function willy-nilly. You should have good reason for using a function pointer.
there is no reason it shouldn't just be a function
Not having to make a bunch of stupid function calls in a tight inner loop of speed-critical code, for something that's very easily and efficiently handled as a macro?
Name:
Anonymous2010-09-13 22:02
#include <stdint.h>
#define clampx(x,T) \
static inline T clamp##x(T n, T lo, T hi) { \
if (n < lo) return lo; \
if (n > hi) return hi; \
return n; \
}
clampx(i, int)
clampx(l, long)
clampx(ll, long long)
clampx(j, intmax_t)
>>49-50
C compilers tend to have an inlining extension, such as __inline/declspec stuff. Common Lisp implementations have inline/notinline declarations as well, however unlike the C ones, those are specified in the standard, however some Lispers(including me), believe that those 2 are themselves not enough as one might want to be able to control wether function calls are direct or indirect too, which is more important in Lisp as it allows redefinition at runtime (of just about anything you can think of).