Smaller size at runtime (uses less memory).
Smaller generated code.
Faster at runtime.
Faster compilation times.
Smaller implementation.
Implementation that you can understand.
How is it worse?
std::function + lambda with variable capture has better ergonomics i.e. less typing.
Also I copy pasted the code from the post and I got this:
test.cpp:70:14: error: assigning to 'void ' from 'func0Ptr' (aka 'void ()(void *)') converts between void pointer and function pointer 70 | res.fn = (func0Ptr)fn;
This warning is stupid. It's part of the "we reserve the right to change the size of function pointers some day so that we can haz closures, so you can't assume that function pointers and data pointers are the same size m'kay?" silliness. And it is silly: because the C and C++ committees will never be able to change the size of function pointers, not backwards-compatibly. It's not that I don't wish they could. It's that they can't.
I also believe there are platforms where a function pointer and a data pointer are not the same but idk about such esoteric platforms first hand (seems Itanium had that: https://stackoverflow.com/questions/36645660/why-cant-i-cast...)
Though my point was only that this code will not compile as is with whatever clang Apple ships*
I am not really sure how to get it to compile tbqh
Some further research ( https://www.kdab.com/how-to-cast-a-function-pointer-to-a-voi...) suggest it should be done like so:
> auto fptr = &f; void a = reinterpret_cast<void &>(fptr);
edit: I tried with GCC 15 and that compiled successfully
res.fn = (void *)fn;
Separately from that, if you enable -Wpedantic, you can get a warning for conversions between function and data pointers even if they do use an explicit cast, but that's not the default.
Note that conversion from a void * pointer to a function
pointer as in:
fptr = (int (*)(int))dlsym(handle, "my_function");
is not defined by the ISO C standard. This standard
requires this conversion to work correctly on conforming
implementations.It works in msvc but as someone pointed out, it was a typo and was meant to be (void*) cast.
My unanswered question on this from 8 years ago:
https://stackoverflow.com/questions/41385439/named-c-lambdas...
If there was a way to name lambdas for debug purposes then all other downsides would be irrelevant (for most usual use cases of using callbacks).
Instead of fully avoiding lambdas, you can use inheritance to give them a name: https://godbolt.org/z/YTMo6ed8T
Sadly that'll only work for captureless lambdas, however.
What I'm trying to say is being better than x means you can do all the same things as x better. Your thing is not better, it is just different.
How much smaller is it? Does it reduce the binary size and RAM usage by just 100 bytes?
Is it actually faster?
How much faster does it compile? 2ms faster?
I wrote it to share my implementation and my experience with it.
SumatraPDF compiles fast (relative to other C++ software) and is smaller, faster and uses less resources that other software.
Is it because I wrote Func0 and Func1 to replace std::function? No.
Is it because I made hundreds decisions like that? Yes.
You're not wrong that performance wins are miniscule.
What you don't understand is that eternal vigilance is the price of liberty. And small, fast software.
Proof needed. Perhaps your overall program is designed to be fast and avoid silly bottlenecks, and these "hundred decisions" didn't really matter at all.
Silly bottlenecks are half of the perf story in my experience. The other half are a billion tiny details.
For example C++ can shoehorn you to a style of programming where 50% of time is spent in allocations and deallocations if your code is otherwise optimal.
The only way to get that back is not to use stl containers in ”typical patterns” but to write your own containers up to a point.
If you didn’t do that, youd see in the profiler that heap operations take 50% of time but there is no obvious hotspot.
Yours is smaller (in terms of sizeof), because std::function employs small-buffer optimization (SBO). That is if the user data fits into a specific size, then it's stored inline the std::function, instead of getting heap allocated. Yours need heap allocation for the ones that take data.
Whether yours win or lose on using less memory heavily depends on your typical closure sizes.
> Faster at runtime
Benchmark, please.