would be cool if you could be like (in C):
SomeFunctionType Foo { ... }
I think the reason why function types can't be used to define functions is because there would be no way to assign argument names, so they are pretty useless by themselves, you can't return them, you can't assign them, but you can construct other types with it.
they could, potentially, retain their argument names from the original typedef:
typedef int (FooFunc)(int x, int y);
FooFunc foo0
{ return(x+y); }
but, then again, this is also along the lines of wishing to be able to do something like:
void foo(va_list args...)
{ ... }
basically, to not require the usual va_start / va_end or the need to have an argument before the elipses (it doesn't ask "that" much, as on many targets, va_list support essentially needs to be built into the compiler anyways).
Yeah, it would be cool to be able to do closures in c. When i saw that function typedef (not the function pointer typedef), it almost looked like one could declare a variable of a function type, and assign some value to it. Then I recall variables need a size, and have no answer to that.
So in c, other than declaring a variable as a pointer to a function type, there doesn't seem to be much use for a function type (it does look nice though, I like function_type * more than function_type_ptr).
yeah.
several compilers (GCC, Clang, ...) offer closures as extensions, but nothing is supported in standard C.
in the time back when I had a (sort-of) working C compiler, it had closures, which were full closures (technically a bit closer to JS syntax though).
the main difference (from those provided by GCC) was that basically they were implemented using allocated memory-objects and involved generating an internal runtime call (and would actually quietly fold off closed-over variables into a heap-allocated structure).
(the C compiler sub-project eventually died mostly due to it being fairly slow and very buggy...).
as-is (in my case), it can sort of be done now (with standard C) using API calls (these calls are specific to my codebase), but requires basically putting the closed-over state into a struct, basically like:
typedef int (*foo_closure)(int, int);
struct closure_state_s { int z; };
int closure_function(struct closure_state_s *env, int x, int y)
{ return(x+y+env->z); }
foo_closure SomeFunctionReturningClosure(int z)
{
struct closure_state_s *env;
env=gcalloc(sizeof(struct closure_state_s));
env->z=z;
return((foo_closure)dyllWrapClosure(closure_function, env, "(ii)i"));
}
and with some annoying drawbacks:
with this interface, it is necessary to manually free the closures and environments later (though they will be reclaimed by the GC on x86-based targets);
the pool is finite-sized on ARM (with a relatively small number of closure-handles available, *);
there is a certain amount of cost in creating them (involves allocating memory and generating the relevant machine-code for the stub);
as can be noted from the code, it is sort of a hassle;
...
*: the ARM version uses a plain-C implementation, which comes at a bit of a cost in terms of performance, and requires essentially procedurally generating a big mass of code which basically read-off the argument list and then invoke a "generic function-dispatch" mechanism (basically, a gigantic procedurally generated "switch()"), making the whole thing a bit bulky and slow. there may also only be a small number of available function-handles available for a given set of argument and return types.
the x86 and x86-64 versions are a bit faster though, as they dynamically generate machine-code stubs which more directly marshal the arguments lists.
there are restrictions though on certain targets (Linux x86-64), mostly in that the particularly complex ABI means that some cases are not handled (my stuff generally only supports a subset of the SysV/AMD64 ABI, using "simplified" rules in a lot of edge-cases, which while not generally an issue, mean that some potential argument lists (generally those involving passing/returning structs) may fail potentially violently).
generally, argument lists containing primitive types and/or pointers and with fewer than 6 arguments are fairly safe though (this is what is supported by the plain-C version), though the generated-machine-code versions are a bit more capable (pretty much arbitrary argument lists are supported, and there is no specific limit as to the available number of closures).
this leaves their main use-case mostly for trying to optimize cross-language API calls (mostly C->script calls), which (as-such) are still fairly expensive (at present, often around 200-500 clock cycles, though mostly due to API issues, and with a lot of "generic C interpreter logic" getting in the way. getting it faster would likely involve making the C<->script interface look and behave a bit more like COM+ or similar, with calls more directly into the compiled script code...).
or such...
