On 29/11/2023 08:50, Matthias Pfaller wrote:
On 2023-11-28 19:00, David Brown wrote:
> Can I ask (either or both of you) why you are using are using nested
functions like
> this? This is possibly the first time I have heard of anyone using
them, certainly
> the first time in embedded development. Even when I programmed in
Pascal, where
> nested functions are part of the language, I did not use them more
than a couple of
> times.
>
> What benefit do you see in nested functions in C, compared to having
separate
> functions? Have you considered moving to C++ and using lambdas,
which are more
> flexible, standard, and can be very much more efficient?
>
> This is, of course, straying from the topicality of this mailing
list. But I am
> curious, and I doubt if I am the only one who is.
- I'm maintaining our token threaded forth interpreter. In the inner
loop there is a absurdly big switch for the primitives. I'm loading rp,
sp and tos into local variables. pushing, popping and memory access is
done by nested functions (checking for stack over and under flows,
managing tos, access violations, ...). Of course that could be done by
macros. But when I'm calling C-functions from within the switch I'll
sometimes pass pointers to the local functions (e.g. for catch/throw
exception handling).
- When calling list iterators, I'm sometimes passing references to
nested functions
- When locking is necessary and the function has multiple return points
I'm doing something like:
void somefunction(void)
{
void f(void)
{
...
}
lock();
f();
unlock();
}
I know, in a lot of cases I could just define some outer static function
or use gotos. But to my eye it just looks nicer that way. In most cases
there will be no trampoline necessary anyway. Its not used that often
and we could probably get rid of it in most cases by using macros and ({
... }).
Thanks for that.
I can appreciate that local functions can look nicer than macros or goto
spaghetti. In simple cases (which is probably the majority for your
usage), the local functions will be inlined and will give pretty much
exactly the same code as you'd get for macros, outer static functions,
or other methods. But I'd be very unhappy to see trampolines here, as
you will need for more complicated cases. The overheads are not
something you'd want to see in the inner loop of an interpreter.
AFAIUI, the reason the compiler has to generate trampolines here is to
make a function that has access to some of the local variables, while
being shoe-horned into the appearance of a function with parameters that
don't include any extra values or references. If you were, as an
alternative, to switch to C++ and use lambdas instead of nested
functions that all disappears precisely because lambdas do not have to
be forced to match the function signature - the generated lambda can
take extra hidden parameters (and even extra hidden state) as needed.
Of course it's never easy to change these kinds of things in existing
code. And it is particularly difficult to get solutions that work
efficiently on a wide range of compilers or versions.
David
