Anonymous functions in C.

[jacob navia]

Gnu C features some interesting extensions, among others
compound statements that return a value. For instance:

({ int y = foo(); int z;
if (y>0) z = y; else z=-y;
z;
})
A block enclosed by braces can appear within parentheses
to form a block that "returns" a value. This is handy
in some macros, or in other applications.

Actually this construct is nothing more (and nothing less)
than anonymous functions.

Anonymous functions could be really handy in call to qsort,
for instance, where just writing an expression could allow
the compiler to expand the anonymous function at each point of
call (as an inline function) within the qsort algorithm.

This, and other extensions are published in a document
"Potential Extnsions for Inclusion in a revision of
ISO/EIC 98/99" available at

http://www.open-std.org/jtc1/sc22/wg...docs/n1229.pdf

That is the official standard site.

Other Gnu extensions are mentioned in that document, like typeof
for instance, an extension that also lcc-win32 implements.
jacob

[Eric Sosman]

Richard Tobin wrote:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.

But because names in a new scope can shadow outer ones, you have the
problem of inadvertent "variable capture", for example:

#define macro(x) {int t = (x)*2; ...}
...
int t;
macro(t+4);

There are obvious conventions to reduce the problem, but these are
likely to fail if you might have nested macro calls.

Correct me if I'm wrong (it's been known to happen ...),
but I think there's no problem with the example shown. The
scope of the "inner" t begins at the end of its declarator
(6.2.1/7), and the initialization is part of the declarator
(6.7/1). Therefore, in the expanded `int t = (t + 4) * 2;'
the initializer's t refers to the "outer" variable, not to the
variable being initialized.

--
Eric Sosman
es*****@acm-dot-org.invalid

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Eric Sosman wrote:

Richard Tobin wrote:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.

But because names in a new scope can shadow outer ones, you have the
problem of inadvertent "variable capture", for example:

#define macro(x) {int t = (x)*2; ...}
...
int t;
macro(t+4);

There are obvious conventions to reduce the problem, but these are
likely to fail if you might have nested macro calls.

Correct me if I'm wrong (it's been known to happen ...),
but I think there's no problem with the example shown. The
scope of the "inner" t begins at the end of its declarator
(6.2.1/7), and the initialization is part of the declarator
(6.7/1).

The initialization part is not part of the declarator. The grammar
(6.7/1) reads:

init-declarator:
declarator
declarator = initializer

The initializer is part of "init-declarator", which is a combination
of a declarator and an initializer. The initializer is not part of the
declarator itself.

[Eric Sosman]

Harald van Dijk wrote:

Eric Sosman wrote:

>Richard Tobin wrote:

>>In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.
But because names in a new scope can shadow outer ones, you have the
problem of inadvertent "variable capture", for example:

#define macro(x) {int t = (x)*2; ...}
...
int t;
macro(t+4);

There are obvious conventions to reduce the problem, but these are
likely to fail if you might have nested macro calls.

Correct me if I'm wrong (it's been known to happen ...),
but I think there's no problem with the example shown. The
scope of the "inner" t begins at the end of its declarator
(6.2.1/7), and the initialization is part of the declarator
(6.7/1).

The initialization part is not part of the declarator. The grammar
(6.7/1) reads:

init-declarator:
declarator
declarator = initializer

The initializer is part of "init-declarator", which is a combination
of a declarator and an initializer. The initializer is not part of the
declarator itself.

Thanks for the correction. The grammar seems clear enough,
but the wording in 6.7/6 seems unclear:

"[...] The init-declarator-list is a comma-separated
sequence of declarators, each of which may have [...]
an initializer [...]"

I was reading "have" as "incorporat e" or "subsume," but in light
of the grammar I guess it must mean "be accompanied by."

--
Eric Sosman
es*****@acm-dot-org.invalid

[jacob.navia]

Richard Heathfield a écrit :

Michal Nazarewicz said:

>>>Richard Heathfield <rj*@see.sig.in validwrites:
For the record, AIUI the GNU syntax for this is that the compound
statement ends in a single expression whose value is taken as the
value of the whole statement, as the following code fragment (which
is not valid C) illustrates:
>
double area = { double a = r * r * pi; a; }
>
That's a lousy example, though, because it's so pointless. I spent
a few moments trying to think up a genuine use for these things,
and didn't manage it. Of course, that doesn't mean there isn't one.
Michal Nazarewicz said:
AFAIK, those statements where introduced to allow #defining /inline/
functions, like:

#define max(a, b) ({ int _a = (a), _b = (b); _a < _b ? _b : _a; })

Richard Heathfield <rj*@see.sig.in validwrites:

>>Well, this is another lousy example (sorry, Michal!) because it can
be done so easily in standard C:

#define max(a, b) (((a) (b)) ? (a) : (b))

And what about:

int i = 1, j = 0;
int k = max(++i, j);

Understood (multiple eval), but frankly I wouldn't go adding an entire
new language feature just to make extra work for myself when I can
already write this as:

int i = 2, j = 0, k = 2;

and in any case, the C community already knows not to risk such
expressions as yours when using macros. Are we going to muddy the
waters by introducing a language feature which makes it okay sometimes,
provided you're careful in the #define?

I don't see that as a win.

As you may know, macros and function calls are not
easy to distinguish in C.

You HAVE TO KNOW that you are calling a macro and not a function.
You may know that, or you may not.

What is important for language coherence and transparency is that

foo(i++);

evaluates i only once if it is a macro or not.

[Keith Thompson]

Harald van Dijk <tr*****@gmail. comwrites:

Keith Thompson wrote:

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

Without going that far, one obvious use is in macros, since it allows
you introduce new variables in the macro expansion. Of course, you
then run into the question of what's a safe name for those variables
(in Lisp, you traditionally use gensym to generate a variable name,
but that requires a more powerful macro language). Many of the macro
uses can be more cleanly solved with inline functions, but others
depend on being able to access variables that aren't arguments to the
function or macro.

I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.

#define my_abs(x) ({ int y = x; y 0 ? y : -y; })

would fail if called as my_abs(y).

You're right.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"jacob.navi a" <ja***@jacob.re mcomp.frwrites:

Richard Tobin a écrit :

>In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>>I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.

But because names in a new scope can shadow outer ones, you have the
problem of inadvertent "variable capture", for example:
#define macro(x) {int t = (x)*2; ...}
...
int t;
macro(t+4);
There are obvious conventions to reduce the problem, but these are
likely to fail if you might have nested macro calls.

There is only one solution:
make real anonymous functions with arguments, etc.

There is another solution: use ordinary functions (inline if you
like).

How would they look like in C?

No idea.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

jacob.navia said:

<snip>

As you may know, macros and function calls are not
easy to distinguish in C.

It is generally quite simple to find out, if you have decent tools, but
I agree that they are superficially similar in appearance.

You HAVE TO KNOW that you are calling a macro and not a function.

Yes, you do.

You may know that, or you may not.

If you don't, you need to find out.

What is important for language coherence and transparency is that

foo(i++);

evaluates i only once if it is a macro or not.

Nevertheless, the risk exists that it may be evaluated more than once,
and this is well-known within the community. Introducing this new
language feature will not eliminate the risk.

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

[Michal Nazarewicz]

>>Michal Nazarewicz said:

>>>AFAIK, those statements where introduced to allow #defining /inline/
functions, like:

#define max(a, b) ({ int _a = (a), _b = (b); _a < _b ? _b : _a; })

>Richard Heathfield <rj*@see.sig.in validwrites:

>>Well, this is another lousy example (sorry, Michal!) because it can
be done so easily in standard C:

#define max(a, b) (((a) (b)) ? (a) : (b))

Michal Nazarewicz said:

>int i = 1, j = 0;
int k = max(++i, j);

Richard Heathfield <rj*@see.sig.in validwrites:

Understood (multiple eval), but frankly I wouldn't go adding an entire
new language feature just to make extra work for myself when I can
already write this as:

int i = 2, j = 0, k = 2;

and in any case, the C community already knows not to risk such
expressions as yours when using macros. Are we going to muddy the
waters by introducing a language feature which makes it okay sometimes,
provided you're careful in the #define?

I'm not saying we should add this feature. I'm explaining what's it
all about.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl >---<jid:mina86*chr ome.pl>--ooO--(_)--Ooo--

[CBFalconer]

Richard Heathfield wrote:

Michal Nazarewicz said:

.... snip ...

>

>AFAIK, those statements where introduced to allow #defining
/inline/ functions, like:

#define max(a, b) ({int _a = (a), _b = (b); _a < _b ? _b : _a;})

Well, this is another lousy example (sorry, Michal!) because it
can be done so easily in standard C:

#define max(a, b) (((a) (b)) ? (a) : (b))

Doesn't work very well when a and/or b have side effects.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline.net
--
Posted via a free Usenet account from http://www.teranews.com

[Alan Curry]

In article <f0***********@ pc-news.cogsci.ed. ac.uk>,
Richard Tobin <ri*****@cogsci .ed.ac.ukwrote:

>
Anonymous functions are almost always going to be *nested* functions,
which opens the whole can of worms concerning non-local variables.
Can these functions refer to, and modify, variables in the containing
function?

Yes they can. The containing function passes its own frame pointer as an
extra hidden argument to the nested function.

What happens if you return the functions to outside the
scope of the containing function?

That's very similar to returning a pointer to an auto variable. The return
doesn't extend the lifetime of the thing being referenced. When you try to
call the nested function through that returned pointer, the GCC manual warns
us: "all hell will break loose".

A pointer to a nested function is actually 2 pointers: a pointer to the code
and a copy of the frame pointer of the corresponding instance of the
containing function. Whenever a pointer to a nested function is required, a
wrapper function is dynamically created to encapsulate those 2 pointers.
Passing this wrapper-pointer down to qsort works fine, but you can't return
it. Not only does it require the use of the containing function's local
variables which are now dead, the wrapper function (trampoline) itself died
along with them.

--
Alan Curry
pa****@world.st d.com