when would one use macros and when static inline,
unless the static inline function is referenced
by it's address, it is 'almost' like a macro with
better readability, so why not use static inline
as macros.
On 2012-09-28, sinbad <sinbad.sin...@gmail.com> wrote:
> when would one use macros and when static inline,
> unless the static inline function is referenced
> by it's address, it is 'almost' like a macro with
> better readability, so why not use static inline
> as macros.
I use macros when:
- it's something so simple that the verbosity of the function
definition syntax would add too much visual overhead
- I want a bit of repetitive code to be "pasted" a few times inside a
function, which needs to use a bunch of local variables, in which case
making it a function would recurire that I pass a large amount of
arguments.
- I want to generate code of some sort, say multiple versions of a
polygon rasterizer routine and call the right one depending on the
current state vector, instead of branching a lot in that routine which
would ruin performance on some systems when it's an integral part of
some inner drawing loop.
- I want my code to compile with C89 compilers.
There might by other reasons out there, these are the ones I could pull
from the top of my head right now.
On 2012-09-28, sinbad <sinbad.sin...@gmail.com> wrote:
> when would one use macros and when static inline,
> unless the static inline function is referenced
> by it's address, it is 'almost' like a macro with
> better readability, so why not use static inline
> as macros.
Macros can do syntactic things that functions cannot, like introduce
declarations into the calling environment, control evaluation or
provide new syntax like for_each_element (x, list) { ... }.
(Try writing an inline function do do for_each_element.)
If you *can* write something as an inline function, then do it.
If you cannot, then you have no choice but to try it with a macro.
sinbad wrote:
> when would one use macros and when static inline,
> unless the static inline function is referenced
> by it's address, it is 'almost' like a macro with
> better readability, so why not use static inline
> as macros.
It is for micromanagement fanatics. The compiler is free to ignore the inline, and it usually does if you compile for space optimisation and call the function from two or more different places.
If you want your compiler to decide, use static inline.
If you want it _always_ inlined, use macros.
On 2012-09-28, Johann Klammer <klamm...@NOSPAM.a1.net> wrote:
> sinbad wrote:
>> when would one use macros and when static inline,
>> unless the static inline function is referenced
>> by it's address, it is 'almost' like a macro with
>> better readability, so why not use static inline
>> as macros.
> It is for micromanagement fanatics. The compiler is free to ignore the > inline, and it usually does if you compile for space optimisation and > call the function from two or more different places.
> If you want your compiler to decide, use static inline.
> If you want it _always_ inlined, use macros.
Even if you use static without inline, the compiler can inline anyway.
(For that reason, compilers should really treat inline seriously and
"do it", otherwise what is it for?)
In one recent project, I detect what kind of support there is for inline
using a shell script that compiles code samples. It prepares a suitable
"#define INLINE ..." line in a "config.h" header.
It will detect whether the static keyword is required or not by doing
linkage tests (is there a clash if the same inline function goes into
two translation units).
With gcc in C90 mode (-ansi) it turns out to be:
#define INLINE static __inline__
If I configure to build build the program using g++, then it's just "inline".
The shell code looks like this (but isn't the entire logic because it relies on
some rules in a makefile compile and which link a single program out of
conftest1.c and conftest2.c).
printf "Checking how to declare inline functions ... "
if [ -z "$inline" ] ; then
for inline in \
"inline" "static inline" "extern inline" \
"__inline__" "static __inline__" "extern __inline__" \
"static"
do
cat > conftest1.c <<!
$inline int func(void)
{
return 0;
> when would one use macros and when static inline,
> unless the static inline function is referenced
> by it's address, it is 'almost' like a macro with
> better readability, so why not use static inline
> as macros.
I prefer declaring functions (static, inline, or otherwise) whenever
what I'm doing can be done using functions. I prefer function-like
macros only for the things that they can do, which can't be done by
actual functions. The # and ## operators are the prime examples. Also,
the expansion of a macro that occurs inside the body of a function is
interpreted in the scope of that function, something that would not be
true of a call to a static inline function.
Macros also provide a weak form of genericity - consider, for example,
the max() macro. It's not as convenient, powerful, or type-safe as C++
templates, but in many cases it's better than what can be done in C
using an actual function. C2011 added a _Generic() feature which reduces
the need for using function-like macros for this purpose, but I don't
think it eliminates that need. I could be mistaken - I haven't had time
to really study _Generic().
-- James Kuyper
> On 2012-09-28, Johann Klammer <klamm...@NOSPAM.a1.net> wrote:
>> sinbad wrote:
>>> when would one use macros and when static inline,
>>> unless the static inline function is referenced
>>> by it's address, it is 'almost' like a macro with
>>> better readability, so why not use static inline
>>> as macros.
>> It is for micromanagement fanatics. The compiler is free to ignore the
>> inline, and it usually does if you compile for space optimisation and
>> call the function from two or more different places.
>> If you want your compiler to decide, use static inline.
>> If you want it _always_ inlined, use macros.
> Even if you use static without inline, the compiler can inline anyway.
> (For that reason, compilers should really treat inline seriously and
> "do it", otherwise what is it for?)
In my experience, compilers /do/ treat "inline" seriously. They don't treat it as a command (there are circumstances where it is impossible to inline the function), but they usually treat it as a very heavy hint. So unless you have forced the compiler to out-line the function (by using recursion, taking its address, forgetting to enable optimisations, etc.), then "inline" will normally do exactly that.
Compilers often have additional compiler-specific extensions (such as gcc's "always_inline" and "flatten" attributes) to give even more control over inlining.
As others have said, "static" functions may be inlined anyway - this is particularly true for use-once functions when optimising, or very small functions when optimising hard. In fact, the compiler can - if it wants - inline non-static functions as well. It will have to generate out-line versions too, but these can perhaps be garbage collected at link time if they are not needed.
On Fri, 28 Sep 2012 07:26:47 +0200, Johann Klammer
<klamm...@NOSPAM.a1.net> wrote:
>sinbad wrote:
>> when would one use macros and when static inline,
>> unless the static inline function is referenced
>> by it's address, it is 'almost' like a macro with
>> better readability, so why not use static inline
>> as macros.
>It is for micromanagement fanatics. The compiler is free to ignore the >inline, and it usually does if you compile for space optimisation and >call the function from two or more different places.
>If you want your compiler to decide, use static inline.
>If you want it _always_ inlined, use macros.
While it's mostly theoretical these days, I've seen compilers in the
past (mainframe, Cobol*, in the era of very expensive memory), that
could actually find common code sequences, and "outline" them (IOW
turn them into a subroutine). The point was to generate smaller code.
While I don't know of any compilers that will do it today, at least
theoretically, a compiler optimizing for size could take several macro
invocations meeting the right conditions, and generate a common
subroutine for the code they emit.
So not "always".
*Cobol would have particularly encouraged that optimization because
the lack of proper subroutines (at the time, it's a bit better now),
encouraged considerable replication of code.
> On Fri, 28 Sep 2012 07:26:47 +0200, Johann Klammer
> <klamm...@NOSPAM.a1.net> wrote:
>> sinbad wrote:
>>> when would one use macros and when static inline,
>>> unless the static inline function is referenced
>>> by it's address, it is 'almost' like a macro with
>>> better readability, so why not use static inline
>>> as macros.
>> It is for micromanagement fanatics. The compiler is free to ignore the
>> inline, and it usually does if you compile for space optimisation and
>> call the function from two or more different places.
>> If you want your compiler to decide, use static inline.
>> If you want it _always_ inlined, use macros.
> While it's mostly theoretical these days, I've seen compilers in the
> past (mainframe, Cobol*, in the era of very expensive memory), that
> could actually find common code sequences, and "outline" them (IOW
> turn them into a subroutine). The point was to generate smaller code.
> While I don't know of any compilers that will do it today, at least
> theoretically, a compiler optimizing for size could take several macro
> invocations meeting the right conditions, and generate a common
> subroutine for the code they emit.
I haven't checked their current offerings, but Green Hills embedded compiler had a space optimisation mode that did just that. I'm sure other embedded compilers offer similar options. Memory doesn't have to be expensive to be a limited resource.
> when would one use macros and when static inline,
> unless the static inline function is referenced
> by it's address, it is 'almost' like a macro with
> better readability, so why not use static inline
> as macros.
Amazingly, no-one mentioned static initialization.
Those of us who live with const data really and truly can't replace initializer macros with functions, inline or not.
- Ark
