Comment by mandarax8 6 months ago
What he shows here is 75% of c++26's std::function_ref. It's mainly missing variadic arguments and doesn't support all types of function objects.
https://github.com/TartanLlama/function_ref/blob/master/incl...
It's not that complex if you remove all the stuff you don't use: https://godbolt.org/z/rM9ejojv4 .
Main things you would need to understand is specialization (think like pattern matching but compile time) and pack expansion (three dots).
Consider this implementation:
Do you understand how your compiler works? Shouldn't you be writing assembly instead? You can't understand all internals and that's perfectly fine.
Why do you even care how std::function is implemented? (Unless you are working in very performance critical or otherwise restricted environments.)
I've listed several reasons why I decided to write and use this implementation:
- better call stacks in crash reports
- smaller and faster at runtime
- faster compilation because less complicated, less templated code
- I understand it
Did I loose useful attributes? Yes. There's no free lunch.
Am I going too far to achieve small, fast code that compiles quickly? Maybe I do.
My code, my rules, my joy.
But philosophically, if you ever wonder why most software today can't start up instantly and ships 100 MB of stuff to show a window: it's because most programmers don't put any thought or effort into keeping things small and fast.
Oh, I definitely agree with some of your other points, just not the one I argued against.
BTW, I would also contest that your version is faster at runtime. Your data always allocated on the heap. Depending on the size of the data, std::function can utilize small function optimization and store everything in place. This means there is no allocation when setting the callback and also better cache locality when calling it. Don't make performance claims without benchmarking!
Similarly, the smaller memory footprint is not as clear cut: with small function optimization there might be hardly a difference. In some cases, std::function might even be smaller. (Don't forget about memory allocation overhead!)
The only point I will absolutely give you is compilation times. But even there I'm not sure if std::function is your bottleneck. Have you actually measured?
Fair enough :) Unfortunately, this is just something one has to accept as a C++ programmer. Should we roll our own std::vector because we can't understand the standard library implemention? The answer is, of course, a firm "no" (unless you have very special requirements).
I can honestly say that I couldn't write that thing in 100 years.
I can't even read it.
That's the fundamental problem with C++: I've understood pretty much all Go code I ever looked at.
The code like the above is so obtuse that 0.001% of C++ programmers is capable of writing it and 0.01% is capable of understanding it.
Sure, I can treat it as magic but I would rather not.