macro and static inline
 

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.

Re: macro and static inline
 

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.

Re: macro and static inline
 

On 2012-09-28, sinbad <sinbad.sinbad@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.

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

Re: macro and static inline
 

On 2012-09-28, sinbad <sinbad.sinbad@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.

Re: macro and static inline
 

On 2012-09-28, Johann Klammer <klammerj@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;
}

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

Re: macro and static inline
 

On 09/28/2012 12:51 AM, 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.

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

Re: macro and static inline
 

On 9/28/2012 12:51 AM, 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.
>
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