void (*fn)(void*, T) = nullptr;Two, my main objective is extreme simplicity and understandability of the code.
I explicitly gave up features of std::function for smaller code that I actually understand.
fu2 seems to be "std::function but more features".
Today, if I was starting from scratch, I would try zig or odin or maybe even Go.
But SumatraPDF started 15 years. There was nothing but C++. And a much different C++ that C++ of today.
Plus, while my own code is over 100k lines, external C / C++ libraries are multiple of that so (easy) integration with C / C++ code is a must.
I hear you about "back in my day," but since as best I can tell it's just your project (that is, not a whole team of 50 engineers who have to collaborate on the codebase) so you are the audience being done a disservice by continuing to battle a language that hates you
As for the interop, yes, since the 70s any language that can't call into a C library is probably DoA but that list isn't the empty set, as you pointed out with the ones you've actually considered. I'd even suspect if you tried Golang it may even bring SumatraPDF to other platforms which would be another huge benefit to your users
Probably by using a cross-platform toolkit written in C++.
But you didn't respond: which language should I use?
Go didn't exist when I started SumatraPDF.
And while I write pretty much everything else in Go and love the productivity, it wouldn't be a good fit.
A big reason people like Sumatra is that it's fast and small. 10 MB (of which majority are fonts embedded in the binary) and not 100MB+ of other apps.
Go's "hello world" is 10 MB.
Plus abysmal (on Windows) interop with C / C++ code.
And the reason SumatraPDF is unportable to mac / linux is not the language but the fact that I use all the Windows API I can for the UI.
Any cross-platform UI solution pretty much require using tens of megabytes of someone else's reimplementation of all the UI widgets (Qt, GTK, Flutter) or re-implementing a smaller subset of UI using less code.
std::pair<void(*)(FuncData*), std;:unique_ptr<FuncData>>
But I do know the code I write and you're wrong about performance of Func0 and Func1. Those are 2 machine words and all it takes to construct them or copy them is to set those 2 fields.
There's just no way to make it faster than that, both at runtime or at compile time.
The whole point of this implementation was giving up fancy features of std::function in exchange for code that is small, fast (both runtime and at compilation time) and one that I 100% understand in a way I'll never understand std::function.
void Call(T arg) const {
if (fn) {
fn(userData, arg);
}
}
void Call(T&& arg) const {
if (fn) {
fn(userData, std::forward<T>(arg));
}
}
std::vector<double> foo();
void bar(Func1<std::vector<double>> f) {
auto v = foo();
f(std::move(v));
}You also have to heap allocate your userData, which is something std::function<> avoids (in all standard implementations) if it’s small enough (this is why the sizeof() of std::function is larger than 16 bytes, so that it can optionally store the data inline, similar to the small string optimization). The cost of that heap allocation is not insignificant.
If I were doing this, I might just go the full C route and just use function pointers and an extra ”userData” argument. This seems like an awkward ”middle ground” between C and C++.
class OnListItemSelected {
OnListItemSelectedData data;
void operator()(int selectedIndex) { ... }
}
The one thing the author's solution does which this solution (and lambdas) does not is type erasure: if you want to pass that closure around, you have to use templates, and you can't store different lambdas in the same data structure even if they have the same signature.
You could solve that in your case by making `void operator()` virtual and inheriting (though that means you have to heap-allocate all your lambdas), or use `std::function<>`, which is a generic solution to this problem (which may or may not allocate, if the lambda is small enough, it's usually optimized to be stored inline).
I get where the author is coming from, but this seems very much like an inferior solution to just using `std::function<>`.
I think whether or not you have to allocate from the heap depends on the lifetime of the lambda. Virtual methods also work just fine on stack-allocated objects.
> OnListItemSelectedData data;
In this case you can just store the data as member variables. No need for defining an extra class just for the data.
As I've written elsewhere, you can also just use a lambda and forward the captures and arguments to a (member) function. Or if you're old-school, use std::bind.
There are numerous differences between my Func0 and Func1<T> and std::function<>.
Runtime size, runtime performance, compilation speed, understandability of the code, size of the source code, size of the generated code, ergonomics of use.
My solution wins on everything except ergonomics of use.
LLVM has a small vector class.
When asked for comment, pjmlp said: "Another example of NIH, better served by using the standard library".
In danger of pointing out the obvious: std::function does note require lambdas. In fact, it has existed long before lambdas where introduced. If you want to avoid lambdas, just use std::bind to bind arguments to regular member functions or free functions. Or pass a lambda that just forwards the captures and arguments to the actual (member) function. There is no reason for regressing to C-style callback functions with user data.
A simple example. If you were to bind a function pointer in one stack frame, and the immediately return it to the parent stack frame which then invokes that bound pointer, the stack that bound the now called function would literally not exist anymore.
There are 2 aspects to this: programmer ergonomics and other (size of code, speed of code, compilation speed, understandability).
Lambdas with variable capture converted to std::function have best ergonomics but at the cost of unnamed, compiler-generated functions that make crash reports hard to read.
My Func0 and Func1<T> approach has similar ergonomics to std::bind. Neither has the problem of potentially crashing in unnamed function but Func0/Func1<T> are better at other (smaller code, faster code, faster compilation).
It's about tradeoffs. I loved the ergonomics of callbacks in C# but I working within limitations of C++ I'm trying to find solutions with attributes important to me.
I would really question your assumptions about code size, memory usage and runtime performance. See my other comments.
https://github.com/TartanLlama/function_ref/blob/master/incl...
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.
Why do you even care how std::function is implemented? (Unless you are working in very performance critical or otherwise restricted environments.)
- 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.
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?
All others use a pointer to an object that exists anyway. For example, I have a class MyWindow with a button. A click callback would have MyWindow* as an argument because that's the data needed to perform that action. That's the case for all UI widgets and they are majority uses of callbacks.
I could try to get cheeky and implement similar optimization as Func0Fat where I would have inline buffer on N bytes and use it as a backing storage for the struct. But see above for why it's not needed.
As to benchmarking: while I don't disagree that benchmarking is useful, it's not the ace card argument you think it is.
I didn't do any benchmarks and I do no plan to.
Because benchmarking takes time, which I could use writing features.
And because I know things.
I know things because I've been programming, learning, benchmarking for 30 years.
I know that using 16 bytes instead of 64 bytes is faster. And I know that likely it won't be captured by a microbenchmark.
And even if it was, the difference would be miniscule.
So you would say "pfft, I told you it was not worth it for a few nanoseconds".
But I know that if I do many optimizations like that, it'll add up even if each individual optimization seems not worth it.
And that's why SumatraPDF can do PDF, ePub, mobi, cbz/cbr and uses less resources that Windows' start menu.
> I just looked and out of 35 uses of MkFunc0 only about 3 (related to running a thread) allocate the args.
In that case, std::function wouldn't allocate either.
> All others use a pointer to an object that exists anyway. For example, I have a class MyWindow with a button. A click callback would have MyWindow* as an argument because that's the data needed to perform that action. That's the case for all UI widgets and they are majority uses of callbacks.
That's what I would have guessed. Either way, I would just use std::bind or a little lambda:
struct MyWindow { void onButtonClicked(); };
// old-school: std::bind
setCallback(std::bind(&MyWindow::onButtonClicked, window));
// modern: a simple lambda
setCallback([window]() { window->onButtonClicked(); });
> I know things because I've been programming, learning, benchmarking for 30 years.
Thinking that one "knows things" is dangerous. Things change and what we once learned might have become outdated or even wrong.
> I know that using 16 bytes instead of 64 bytes is faster. And I know that likely it won't be captured by a microbenchmark.
Well, not necessarily. If you don't allocate any capture data, then your solution will win. Otherwise it might actually perform worse. In your blog post, you just claimed that your solution is faster overall, without providing any evidence.
Side note: I'm a bit surprised that std::function takes up 64 bytes in 64-bit MSVC, but I can confirm that it's true! With 64-bit GCC and Clang it's 32 bytes, which I find more reasonable.
> And even if it was, the difference would be miniscule.
That's what I would think as well. Personally, I wouldn't even bother with the performance of a callback function wrapper in a UI application. It just won't make a difference.
> But I know that if I do many optimizations like that, it'll add up even if each individual optimization seems not worth it.
Amdahl's law still holds. You need to optimize the parts that actually matter. It doesn't mean you should be careless, but we need to keep things in perspective. (I would care if this was called hundreds or thousands of times within a few milliseconds, like in a realtime audio application, but this is not the case here.)
To be fair, in your blog post you do concede that std::function has overall better ergonomics, but I still think you are vastly overselling the upsides of your solution.
C++ takes this to another level, though. I'm not an expert Go or Rust programmer, but it's much easier to understand the code in their standard libraries than C++.
The problem with that is that for every type of callback you need to create a base class and then create a derived function for every unique use.
That's a lot of classes to write.
Consider this (from memory so please ignore syntax errors, if any):
class ThreadBase {
virtual void Run();
// ...
}
class MyThread : ThreadBase {
MyData* myData;
void Run() override;
// ...
}
StartThread(new MyThread());
HANDLE StartThread(const Func0&, const char* threadName = nullptr);
auto fn = MkFunc0(InstallerThread, &gCliNew);
StartThread(fn, "InstallerThread");
This is replaced by Func0 or Func1<T>. No new classes, much less typing. And less typing is better programming ergonomics.
std::function arguably has slightly better ergonomics but higher cost on 3 dimension (runtime, compilation time, understandability).
In retrospect Func0 and Func1 seem trivial but it took me years of trying other approaches to arrive at insight needed to create them.
An interface declaration is, like, two lines. And a single receiver can implement multiple interfaces. In exchange, the debugger gets a lot more useful. Plus it ensures the lifetime of the "callback" and the "context" are tightly-coupled, so you don't have to worry about intersecting use-after-frees.
I haven’t used windows in a long time but back in the day I remember installing SumatraPDF to my Pentium 3 system running windows XP and that shit rocked
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
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.
not-so-darkstar•7h ago
kjksf•7h ago
Somehow my blog server got overwhelmed and requests started taking tens of seconds. Which is strange because typically it's under 100ms (it's just executing a Go template).
It's not a CPU issues so there must be locking issue I don't understand.