macro and static inline

[sinbad]

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.

[John Tsiombikas]

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.

--
John Tsiombikas
http://nuclear.mutantstargoat.com/

[Kaz Kylheku]

On 2012-09-28, sinbad <sinbad...@gmail.com> wrote:

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.

[Johann Klammer]

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.

[Kaz Kylheku]

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;
}

int main(void)
{
return func();
}
!
cat > conftest2.c <<!
$inline int func(void)
{
return 0;
}
!
rm -f conftest2
if ! $make conftest2 > conftest.err 2>&1 ; then
continue
fi
break
done
fi

printf '"%s"\n' "$inline"
printf "#define INLINE $inline\n" >> config.h

[James Kuyper]

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

[David Brown]

On 28/09/2012 07:39, Kaz Kylheku wrote:
> On 2012-09-28, Johann Klammer <klam...@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.

[Robert Wessel]

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.

[Ian Collins]

On 09/29/12 05:02 AM, Robert Wessel wrote:
> On Fri, 28 Sep 2012 07:26:47 +0200, Johann Klammer
> <klam...@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.

--
Ian Collins

[Ark]

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