使用宏来进行小型操作，这是一种很好的做法吗？

Question

I have a small piece of code that requires to read 4-bit values bitpacked in a 32-bit integer. Since I need to call this operation several times, even if it's simple, I require max speed on it. I was pondering about macros and inline functions, thus I made this macro:

#define UI32TO4(x, p) (x >> ((p - 1) *4) & 15)

And I have an inline function that does the same thing.

static inline Uint8 foo_getval(Uint32 bits, int pos){
    return (bits >> ((pos-1)*4)) & 15;
}

Considering the simplicity of the operation, and that the values are already prepared for this call (so no possibility of calling on the wrong types, or pass values that are too big or that stuff), what would be the best one to use? Or, at least, the most comprehensible for someone else potentially reading/modifying the code later on?

EDIT! Forgot to mention, I am using C99.

Answer 1

The function is safer. Your assumptions that the values are always "right" only holds while you're developing that code. You can't tell if someone down the line (or yourself when you're tired) won't pass unexpected values.

The compiler will do the inlining when it sees it as effective. Use type-safe functions whenever you can, use macros only when you have no other practical choice.

Answer 2

I would use the inline function because macros can cause unwanted side effects. Use macros only to save typing if necessary.

If a macro name is the same name as a function name in an other compilation unit you would get strange compilation errors. These problems can be hard to find, especially if the macro is expanded elsewhere and no error occurs.

Additionally a function warns you about parameter types and would not let you give a double for pos. The macro could allow this.

Answer 3

It's late, and I'm grumpy (and I'll probably delete this post later) but I get tired of hearing the same arguments against macros parroted over and over again (a double redundacy):

• Joachim Pileborg (above) states "using a function allows the compiler to do better typechecking". This is often stated , but I don't believe it. With macros, the compiler already has all the available type information at its fingertips. Functions simply destroy this. (And possibly destroy optimization, by pushing registers out to the stack, but that's a side issue.)

• And frast (above) states "macros can cause unwanted side effects". True--but so can functions. I think the rule is to always use UPPER_CASE for macros which don't have function semantics. This rule has often been broken. But it doesnt apply here: the OP has redundantly used both uppercase and function semantics.

But I would suggest a tiny improvement. The OP has quite correctly placed parentheses around the whole macro, but there should also be parentheses around each argument:

   #define UI32TO4(x, p) ((x) >> (((p) - 1) * 4) & 15)

Always enclose your macro args in parentheses, unless you are doing string or token concatenting, etc.

Macros are, of course, dangerous, but so are functions. (And the less said of STL, the better).