There was a time when C programmers 'inlined' frequently used functions. To eliminate overhead of calling another function. Like this (found in GNU coreutils):
/* Given an unsigned 16-bit argument X, return the value corresponding to X with reversed byte order. */ #define bswap_16(x) ((((x) & 0x00FF) << 8) | \ (((x) & 0xFF00) >> 8)) /* Given an unsigned 32-bit argument X, return the value corresponding to X with reversed byte order. */ #define bswap_32(x) ((((x) & 0x000000FF) << 24) | \ (((x) & 0x0000FF00) << 8) | \ (((x) & 0x00FF0000) >> 8) | \ (((x) & 0xFF000000) >> 24))
'Inlining' happens during preprocessor phase. And it was sensible for old C compilers which didn't support 'inline' keyword or couldn't inline automatically.
But such a code is ugly by today's standards, and error-prone. Either use 'inline' keyword for most busy and small functions. Or compiler could inline such functions automatically during optimization phase.
But I write this post for those who would like to understand better what 'inlining' means on low-level. And why it's sometimes sensible to 'inline' function instead of calling it.
List of my other blog posts.
Subscribe to my news feed
Yes, I know about these lousy Disqus ads. Please use adblocker. I would consider to subscribe to 'pro' version of Disqus if the signal/noise ratio in comments would be good enough.