inline functions vs. macros

[Robert Seacord]

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

What sort of things is it still reasonable to do using macros? For
example, is it reasonable to write type generic functions macros?

#define CUBE(I) ( (I) * (I) * (I) )

Is there some more concise set of things where inline functions should
be used instead of macros? Multi-statement macros, for example?

Thanks,
rCs

[Ben Pfaff]

Robert Seacord <rc*@sei.cmu.eduwrites:

Is there some more concise set of things where inline functions should
be used instead of macros? Multi-statement macros, for example?

In general, if an inline function can be used, it should be
used. Inline functions are much less likely to cause nasty
surprises than macros, so they are preferred.
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro

[Darko]

Well, as the majority probably know, macros are really tricky to use
and one should be very careful with them. The best example I know when
they shouldn't be used, is the following:

#define max(a,b) ((a)>(b)?(a):(b))
int x = 4, y = 5;
int z = max(x++, y++);

One would expect the x and y to be incremented once each, but the fact
is the text renders into the following:
int z = ((x++)>(y++)?(x++):(y++)),
which means the bigger of the two will get incremented twice instead of
only once.

Robert Seacord wrote:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

What sort of things is it still reasonable to do using macros? For
example, is it reasonable to write type generic functions macros?

#define CUBE(I) ( (I) * (I) * (I) )

Is there some more concise set of things where inline functions should
be used instead of macros? Multi-statement macros, for example?

Thanks,
rCs

[Andrey Tarasevich]

Robert Seacord wrote:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

In cases when the both methods are interchangeable - of course, using inline
functions is a better idea.

What sort of things is it still reasonable to do using macros?

There are lots of things that can only be done with macros. Macros can be used
as a substitute for absolutely any piece of code and that means a lot.

For example, one can use macros to generate object and function declarations and
definitions. One can use macros to implement "local functions" (repetitive
pieces of code that have access to automatic variables from the enclosing
scope). Functionality of macros can be used to simulate functionality of
templates in C++.

When macros are used to implement "functions" they can be made to support
certain form of "lazy calculation". For example, the following macro

#define SELECT(s, v1, v2) ((s) ? (v1) : (v2))

will calculate only one of the two expressions depending on the selector's value
(cannot be achieved with an inline function).

And so on. Again, there are lots of other things that can only be done with
macros. One just have to keep in mind that benefits of macros often come with a
considerable number of drawbacks, meaning that one has to use macros with
caution. Nevertheless, the popular belief that macros should be avoided at all
costs makes absolutely no sense. But in situations where macros and inline
functions offer the same functionality it is better to stick with inline functions.

For
example, is it reasonable to write type generic functions macros?

#define CUBE(I) ( (I) * (I) * (I) )

Well, if the key point here is to have a type-generic "function", then it is
reasonable. However, in a simple case like this it might prove to be a better
decision to just write several inline functions with different names. Actually,
macros can still be used to do the latter as shown below:

#define DEFINE_CUBE(T, s) inline T cube_##s(T v) { return v * v * v; }

DEFINE_CUBE(double, d)
DEFINE_CUBE(int, i)
DEFINE_CUBE(unsigned, ui)

--
Best regards,
Andrey Tarasevich

[Richard Heathfield]

Darko said:

Well, as the majority probably know, macros are really tricky to use

I agree that macros do require a modicum of care, particularly if their
arguments are evaluated more than once, but I wouldn't go so far as to say
they're really tricky. Yes, okay, you can /make/ them tricky, but then you
can make functions tricky, too.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ancient_Hacker]

Robert Seacord wrote:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

They're apples versus kittens. About all they have in common is
they're both edible.

With a macro you're assured it's going to get expanded as text right
there. Now is it assured an inline function will get expanded inline?

With a macro you can call it in any context, with or without parens,
and it will generate almost any syntactical mess. A function can only
be used in certain contexts, executable, and must have parens.

macros have their place when you need some bizarre declaration or
executable code.
For instance since C doesnt have a "with" statement, you have to write:

Application->WindowList[ Message->WindowIndex ]->Next->Panel->Title =
"syph";
Application->WindowList[ Message->WindowIndex ]->Next->Panel->Font =
"Aramaic";
Application->WindowList[ Message->WindowIndex ]->Next->Panel->Style =
S_BOLD;
Application->WindowList[ Message->WindowIndex ]->Next->Panel->Align=
AA_RIGHT;

.... which just cries out for some factoring. One way is to (ouch) use
a macro.

[John Bode]

Robert Seacord wrote:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

What sort of things is it still reasonable to do using macros? For
example, is it reasonable to write type generic functions macros?

#define CUBE(I) ( (I) * (I) * (I) )

It is, until someone innocently writes

x = CUBE(y++);

and gets undefined behavior for their trouble.

Is there some more concise set of things where inline functions should
be used instead of macros? Multi-statement macros, for example?

Thanks,
rCs

Remember that the C preprocessor is strictly a text substitution
mechanism; it does not know or care about scope, or type, or syntax, or
anything else. Therefore, using preprocessor macros to simulate inline
functions or to fake generic programming is generally a bad idea for
anything other than the most simple of expressions, and even then you
have to beware of situations like the one I describe above.

If you need a function-like operation, then use an actual function,
whether it's inline or not. If you're concerned about efficiency, use
a profiling tool to find the real bottlenecks; don't just blindly
convert functions to macros in the hopes that it will speed things up.

If you want generics, use C++ or some other language that supports
them. Trying to fake it in C is often more trouble than it's worth.

[Ian Collins]

Ancient_Hacker wrote:

Robert Seacord wrote:

>>When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

They're apples versus kittens. About all they have in common is
they're both edible.

With a macro you're assured it's going to get expanded as text right
there. Now is it assured an inline function will get expanded inline?

With a macro you can call it in any context, with or without parens,
and it will generate almost any syntactical mess. A function can only
be used in certain contexts, executable, and must have parens.

macros have their place when you need some bizarre declaration or
executable code.
For instance since C doesnt have a "with" statement, you have to write:

Application->WindowList[ Message->WindowIndex ]->Next->Panel->Title =
"syph";
Application->WindowList[ Message->WindowIndex ]->Next->Panel->Font =
"Aramaic";
Application->WindowList[ Message->WindowIndex ]->Next->Panel->Style =
S_BOLD;
Application->WindowList[ Message->WindowIndex ]->Next->Panel->Align=
AA_RIGHT;

.... which just cries out for some factoring. One way is to (ouch) use
a macro.

Or
PanelType *panel =
&Application->WindowList[Message->WindowIndex]->Next->Panel;

--
Ian Collins.

[Frederick Gotham]

Robert Seacord posted:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

Not in general, no, for three reasons:

(1) C90 doesn't support inline.
(2) Even if the compiler _does_ support inline, the code is guaranteed to
be inlined.
(3) It doesn't yield a compile-time constant.

What sort of things is it still reasonable to do using macros? For
example, is it reasonable to write type generic functions macros?

Yes, it's grand.

#define CUBE(I) ( (I) * (I) * (I) )

This one evaluates its argument more than once, but that's OK since the
macro name is in ALL CAPS, which serves as a warning to the programmer.

Is there some more concise set of things where inline functions should
be used instead of macros? Multi-statement macros, for example?

If you need to define variables _and_ return a value, you might need a
function.

--

Frederick Gotham

[Christopher Benson-Manica]

Frederick Gotham <fg*******@spam.comwrote:

(1) C90 doesn't support inline.
(2) Even if the compiler _does_ support inline, the code is guaranteed to

^^ isn't

be inlined.
(3) It doesn't yield a compile-time constant.

A macro might not either; much good and evil can be done with macros.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Andrew Poelstra]

On Wed, 2006-10-18 at 21:16 +0000, Frederick Gotham wrote:

Robert Seacord posted:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

Not in general, no, for three reasons:

(1) C90 doesn't support inline.
(2) Even if the compiler _does_ support inline, the code is guaranteed to
be inlined.

You meant /not/ guaranteed to be inline. According to C99, that is.

--
Andrew Poelstra <http://www.wpsoftware.net/projects/>

[Pedro Graca]

Darko top-posted [reordered]:

Robert Seacord wrote:

>When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

Well, as the majority probably know, macros are really tricky to use
and one should be very careful with them. The best example I know when
they shouldn't be used, is the following:

#define max(a,b) ((a)>(b)?(a):(b))
int x = 4, y = 5;
int z = max(x++, y++);

One would expect the x and y to be incremented once each, but the fact
is the text renders into the following:
int z = ((x++)>(y++)?(x++):(y++)),
which means the bigger of the two will get incremented twice instead of
only once.

And if you had defined your macro in ALL UPPERCASE, someone writing

int z = MAX(x++ .... hey! it's MAX in all uppercase
.... must be a macro, let me do it like this instead

x++; y++;
int z = MAX(x, y); /* wheew! good thing the original programmer
used ALL UPPERCASE for this macro :) */

--
File not found: (R)esume, (R)etry, (R)erun, (R)eturn, (R)eboot

[websnarf]

Robert Seacord wrote:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

For the purposes of portability or long term viability/maintainability,
use of C99 is *not* a reasonable recommendation. You should use C
compilers that will have long term support, or otherwise write code to
the lowest common denominator (portable C/C++.)

Keep in mind that "static" function declarations are usually basically
equivalent to what is intended by C99's "inline". For serious
compilers, there should be no effective difference between the two
(inline further asserts that taking the address of the function is
illegal, however, a static function whose address *isn't* taken (which
it can always determine because it *is* static) becomes equivalent in
functional status.)

What sort of things is it still reasonable to do using macros? For
example, is it reasonable to write type generic functions macros?

#define CUBE(I) ( (I) * (I) * (I) )

Is there some more concise set of things where inline functions should
be used instead of macros?

The general rule of thumb that I use is that complicated macros should
be module local and commented (or obvious). Otherwise, macros should
be limited to constants, or convenience wrappers.

Multi-statement macros, for example?

There's the whole issue of if() else and multi-line macros. The way
you can get around it is to wrap your multi-line macro with a do { ...
} while(0);. Unfortunately many compilers complain that the while (0)
condition is constant and issue a warning. I don't like turning this
warning off in the compiler, because its reasonable if the "0" comes
from some compiler simplifications. So we're kind of in a no-win
scenario here.

Sometimes some kinds of multi-statement macros can lead to interesting
conundrons. Suppose we have the following macro:

#define hf_idxFirst(t,i) {\
i = hf_NOT_FOUND;\
if (NULL != (t)) hf_idxNext(t,i);\
}

This is fine, except that you cannot write code such as this:

for (hf_idxFirst (table, i); !hf_idxIsEnd(table,i);
hf_idxNext(table,i)) {
/* ... */
}

This isn't so much a multi-statement macro issue as much as a control
code fragment limitation issue that gets hidden by a macro.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Keith Thompson]

we******@gmail.com writes:
[...]

Keep in mind that "static" function declarations are usually basically
equivalent to what is intended by C99's "inline". For serious
compilers, there should be no effective difference between the two
(inline further asserts that taking the address of the function is
illegal, however, a static function whose address *isn't* taken (which
it can always determine because it *is* static) becomes equivalent in
functional status.)

I believe it's perfectly legal to take the address of an inline
function. Can you cite something in the standard that says otherwise?
In particular, the function call operator expects a
pointer-to-function, so just calling a function implicitly takes its
address.

(The standard *could* have said that taking the address of an inline
function other than in a direct call is illegal, but it doesn't.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Andrey Tarasevich]

we******@gmail.com wrote:

...
inline further asserts that taking the address of the function is
illegal
...

That's incorrect. There's absolutely nothing illegal in taking the address of an
inline function.

--
Best regards,
Andrey Tarasevich

[Ian Collins]

Frederick Gotham wrote:

Robert Seacord posted:

>>When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

Not in general, no, for three reasons:

(1) C90 doesn't support inline.

The OP asked about C99.

(2) Even if the compiler _does_ support inline, the code is guaranteed to
be inlined.
(3) It doesn't yield a compile-time constant.

?

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Frederick Gotham wrote:

>Robert Seacord posted:

>>>When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

Not in general, no, for three reasons:

(1) C90 doesn't support inline.

The OP asked about C99.

Nevertheless, it's a reasonable point. When writing C99 code, it is for the
time being (and, the way, we're going, for the foreseeable future too)
reasonable to keep the code portable to C90, unless one is prepared to
forego the advantages thereof.

>(2) Even if the compiler _does_ support inline, the code is guaranteed to
be inlined.
(3) It doesn't yield a compile-time constant.

?

I'm not sure what he means by that, either.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Andrew Poelstra said:

On Wed, 2006-10-18 at 21:16 +0000, Frederick Gotham wrote:

>Robert Seacord posted:

When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

Not in general, no, for three reasons:

(1) C90 doesn't support inline.
(2) Even if the compiler _does_ support inline, the code is guaranteed to
be inlined.

You meant /not/ guaranteed to be inline. According to C99, that is.

I am fairly sure he meant something like "[the macro version of] the code is
*guaranteed* to be inlined".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>>Frederick Gotham wrote:

>>>Robert Seacord posted:
When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

Not in general, no, for three reasons:

(1) C90 doesn't support inline.

The OP asked about C99.

Nevertheless, it's a reasonable point. When writing C99 code, it is for the
time being (and, the way, we're going, for the foreseeable future too)
reasonable to keep the code portable to C90, unless one is prepared to
forego the advantages thereof.

True, which brings us back to the old dilemma of pragmatism or
portability. I think every recent (last 10 years) C compiler I've used
either supports inline as an extension, or inlines as an optimisation,
or both.
--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

[...]

>When writing C99 code, it is for
the time being (and, the way, we're going, for the foreseeable future
too) reasonable to keep the code portable to C90, unless one is prepared
to forego the advantages thereof.

True, which brings us back to the old dilemma of pragmatism or
portability.

For me, portability is part of pragmatism.

And so, of course, is non-portability.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>>Richard Heathfield wrote:

[...]

>>>When writing C99 code, it is for
the time being (and, the way, we're going, for the foreseeable future
too) reasonable to keep the code portable to C90, unless one is prepared
to forego the advantages thereof.

True, which brings us back to the old dilemma of pragmatism or
portability.

For me, portability is part of pragmatism.

And so, of course, is non-portability.

Can't argue with that :)

I guess there isn't any way of knowing, but it would be interesting to
know how much C code is truly portable. Probably a small fraction of
one percent.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

<snip>

>>>[...] the old dilemma of pragmatism or portability.

For me, portability is part of pragmatism.

And so, of course, is non-portability.

Can't argue with that :)

I guess there isn't any way of knowing, but it would be interesting to
know how much C code is truly portable. Probably a small fraction of
one percent.

It depends on what you mean, I guess. If we're talking about C *programs*,
the figure is probably quite low, because so many C programs need to take
advantage of platform-specific features. But if we're talking about C
*libraries*, then the figure is considerably higher.

As I have occasionally mentioned before in comp.lang.c, I've worked on quite
a few projects in which portability was considered an extremely high
priority, and yet platform-specific features were required as well. This
dilemma was solved by keeping all the platform-specific stuff carefully
isolated into its own modules, with all the portable stuff in /its/ own
modules. The example I like best was a Web browser for set-top boxes, which
was developed on Windows and Linux (developer's choice!). Of around 500,000
lines of code, only 5,000 (just 1%!) were non-portable. The browser only
took about a person-month to port to each new platform, because of this
careful isolation.

Those who "rubbish" portability because they think it means turning your
back on your program's access to platform-specific features have simply not
thought the issue through. Those who develop *only* for one platform are
less likely to be convinced by the argument for portability, of course - at
least until either their platform vanishes underneath them or their boss
suddenly says "in our next release, we have to support the YAP6000 - get to
it!", whereupon they sit at their desks wondering where they left their CV.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:
[...]

I guess there isn't any way of knowing, but it would be interesting to
know how much C code is truly portable. Probably a small fraction of
one percent.

Probably a small fraction of C programs are truly portable. But a
large proportion of the *code* in a well-written program should be
portable, with the system-specific portions relatively isolated.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Duncan Muirhead]

On Wed, 18 Oct 2006 11:38:56 -0700, John Bode wrote:

>
Robert Seacord wrote:

>When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

What sort of things is it still reasonable to do using macros? For
example, is it reasonable to write type generic functions macros?

#define CUBE(I) ( (I) * (I) * (I) )

It is, until someone innocently writes

x = CUBE(y++);

and gets undefined behavior for their trouble.

<snip>
There can be harder to spot multiple side effects, as in
CUBE(g(x)), where g has side effects. On the other hand if f is
side effect free but the compiler doesn't know that (e.g. f is
in a precompiled library), CUBE(f(x)) would lead to needless
recomputation.

[Richard Tobin]

In article <12*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.comwrote:

>inline further asserts that taking the address of the function is
illegal

>That's incorrect. There's absolutely nothing illegal in taking the
address of an inline function.

The previous poster was probably thinking (correctly) that it's not
usefully possible to take the address of a function that has been
inlined. If you take the address of a function declared inline, the
compiler will have to produce an out-of-line version as well.

-- Richard

[Laurent Deniau]

Richard Tobin wrote:

In article <12*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.comwrote:

>>>inline further asserts that taking the address of the function is
illegal

>>That's incorrect. There's absolutely nothing illegal in taking the
address of an inline function.

The previous poster was probably thinking (correctly) that it's not
usefully possible to take the address of a function that has been
inlined. If you take the address of a function declared inline, the
compiler will have to produce an out-of-line version as well.

Only if it is qualified with static.

a+, ld.

[Ben Pfaff]

Richard Heathfield <in*****@invalid.invalidwrites:

Ian Collins said:

>Frederick Gotham wrote:

>>(3) It doesn't yield a compile-time constant.

?

I'm not sure what he means by that, either.

#define add_m(a, b) ((a) + (b))
static inline add_f(int a, int b) { return a + b; }

add_m(3,4) is a constant expression.
add_f(3,4) is not a constant expression.
--
"We put [the best] Assembler programmers in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of optimization
problem, break glass.' Meanwhile, the problem solvers are busy doing their
work in languages most appropriate to the job at hand." --Richard Riehle

[Robert Seacord]

Thanks for all your responses. I've tried to incorporate them into the
following recommendation "PRE00-A. Prefer inline functions to macros"

http://www.securecoding.cert.org/con...ions+to+macros

Please let me know if I botched anything. 8^)

Thanks,
rCs

[Hallvard B Furuseth]

we******@gmail.com writes:

>Robert Seacord wrote:

>When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?

For the purposes of portability or long term viability/maintainability,
use of C99 is *not* a reasonable recommendation. You should use C
compilers that will have long term support, or otherwise write code to
the lowest common denominator (portable C/C++.)

And one should also take a bit extra care with features like inline,
which were implemented elsewhere and with different semantics before
they became standardized in C99. (At least gcc had them, but I assume
others as well.)

The semantics of extern vs. inline is almost opposite in gcc from the
standard: 'extern inline' is used for a definition which is only
inlined, never compiled on its own. The gcc doc recommends to use
'static inline' only, that's compatible with C99. For inlines in .h
files, if you want to be compatible with not-quite-C99-compilers (which
fits most compilers nowadays), I think you'd need a mess of '#if's used
to #define an Inline macro or something.

--
Hallvard

[Andrey Tarasevich]

Richard Tobin wrote:

...

>>inline further asserts that taking the address of the function is
illegal

>>That's incorrect. There's absolutely nothing illegal in taking the
address of an inline function.

The previous poster was probably thinking (correctly) that it's not
usefully possible to take the address of a function that has been
inlined. If you take the address of a function declared inline, the
compiler will have to produce an out-of-line version as well.
...

Strictly speaking, "has been inlined" is not a property of the function itself.
"Has been inlined" is something that can only be said about each particular
invocation of the function, each particular call. And, as one would expect, it
is applied to each particular call _independently_. One particular call can be
inlined, while the other one might be implemented by a regular call to the
out-of-line version (regardless of whether the address of this inline function
is taken anywhere in the program)

It is true that an attempt to take the addresss of an inline function will make
the compiler to generate the out-of-line body for the function. But I don't see
how this can impact the "usefulness" of the function.

--
Best regards,
Andrey Tarasevich

[Richard Tobin]

In article <12*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.comwrote:

>The previous poster was probably thinking (correctly) that it's not
usefully possible to take the address of a function that has been
inlined. If you take the address of a function declared inline, the
compiler will have to produce an out-of-line version as well.

>Strictly speaking, "has been inlined" is not a property of the
function itself. "Has been inlined" is something that can only be
said about each particular invocation of the function, each
particular call.

Of course I meant "all of whose calls have been inlined".

>It is true that an attempt to take the addresss of an inline function
will make the compiler to generate the out-of-line body for the
function. But I don't see how this can impact the "usefulness" of the
function.

I meant that you could conceivably get the address of the code
corresponding to an inlined call to the function, but that wouldn't be
useful.

-- Richard

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <12*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.comwrote:

[...]

>>It is true that an attempt to take the addresss of an inline function
will make the compiler to generate the out-of-line body for the
function. But I don't see how this can impact the "usefulness" of the
function.

I meant that you could conceivably get the address of the code
corresponding to an inlined call to the function, but that wouldn't be
useful.

No, you couldn't, unless you could use such an address to call the
function with arbitrary arguments.

You can legally take the address of a function (even if it's marked
"inline"), and you can use that address to call that function. That's
what function addresses are for.

Presumably a compiler could use "inline" as a hint that *direct* calls
to the function should be inlined. That doesn't make indirect calls
useless.

For example, I might have a function that computes some mathematical
formula. The formula might be simple enough that the overhead of a
normal function call is significant, so I mark it as "inline". But I
might still want to paas that function's address to, say, a function
that will compute an approximation of its integral over a specified
range. For that, I need its address.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>I meant that you could conceivably get the address of the code
corresponding to an inlined call to the function, but that wouldn't be
useful.

>No, you couldn't, unless you could use such an address to call the
function with arbitrary arguments.

I'm clearly not being clear here. There's (probably) an address at
which the inlined code starts, but it would be useless for the
compiler to give you that as the address of the function, because you
couldn't use it to call the function. I didn't mean it would be
possible for a conforming C compiler to do such a thing.

I should just have left out "usefully" in my original comment:

The previous poster was probably thinking (correctly) that it's not
usefully possible to take the address of a function that has been
inlined.

I only put it in because I was expecting some pedant to say "it is
*possible* to take the address, you just can't call it".

-- Richard

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>>I meant that you could conceivably get the address of the code
corresponding to an inlined call to the function, but that wouldn't be
useful.

>>No, you couldn't, unless you could use such an address to call the
function with arbitrary arguments.

I'm clearly not being clear here. There's (probably) an address at
which the inlined code starts, but it would be useless for the
compiler to give you that as the address of the function, because you
couldn't use it to call the function. I didn't mean it would be
possible for a conforming C compiler to do such a thing.

I should just have left out "usefully" in my original comment:

The previous poster was probably thinking (correctly) that it's not
usefully possible to take the address of a function that has been
inlined.

I only put it in because I was expecting some pedant to say "it is
*possible* to take the address, you just can't call it".

Ok, I see what you mean -- but I think you were mistaken in your
original assumption.

Here's what Paul Hsieh ("websnarf") wrote:
| Keep in mind that "static" function declarations are usually basically
| equivalent to what is intended by C99's "inline". For serious
| compilers, there should be no effective difference between the two
| (inline further asserts that taking the address of the function is
| illegal, however, a static function whose address *isn't* taken (which
| it can always determine because it *is* static) becomes equivalent in
| functional status.)

A couple of followups later, you wrote:
| The previous poster was probably thinking (correctly) that it's not
| usefully possible to take the address of a function that has been
| inlined. If you take the address of a function declared inline, the
| compiler will have to produce an out-of-line version as well.

I'm reasonably sure that Paul *meant* simply that the standard
disallows taking the address of a function to which "inline" has been
applied, just as it does for a variable to which 'register has been
applied. (He was mistaken, though the standard easily *could* have
imposed this restriction, and it arguably would have made some sense.)

Taking the address of an inlined expansion of a function doesn't make
much sense at all, though I suppose it would be theoretically
possible. By anticipating a point that nobody actually made, I'm
afraid you've managed (quite unintentionally, I'm certain) to create
the very confusion you were trying to prevent.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.