I agree: This quote is the star of the show. I'll troll a little bit here: I thought to myself: "Finally, a humble C++ programmer. Really, they do exist... well, at least one."

    > easy things should be easy; hard things should be possible

30 year c++ veteran here. Also don’t know 80%. I used to know more but a combination of way better tooling and “modern” c++ and most importantly realising that thinking more about things other than the language details led to better software meant I have forgotten stuff I used to know.

They don't autogenerate classes anymore, just private static methods though I agree that it would be nice to have more of the metadata in the name of the generated method.

This. I was confused when I read that - I guess MSVC doesn't generate such conventional lambda names ?

Out of curiosity, what's your use case for it? Years ago I preferred Sumatra/Foxit to Adobe, but every major browser has supported rendering PDFs for at least a decade and I haven't had needed or wanted a dedicated PDF reader in all that time.

Indeed, that is exactly the case, lambdas are essentially syntax sugar for doing this.

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<>`.

Exactly! And if you need type erasure, you can just store it in a std::function.

> 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.

Main issue author had with lambdas is autogenerated names in crash reports

It's a daily thing we all do: decide if this problem is better solved by a big chunk of code that is probably well tested but probably satisfies a bunch of requirements and other constraints or a smaller chunk of code that I can write or vendor in and has other advantages or maybe I just prefer how its spelled. Sometimes there's a "right" answer, e.g. you should generally link in your TLS implantation unless you're a professional TLS pereon, but usually its a judgement call, and the aggregate of all those micro-decisions are a component of the intangible ideal of "good taste" (also somewhat subjective but most agree on the concept of an ideal).

In this instance the maintainer of a useful piece of software has made a choice that's a little less common in C++ (totally standard practice in C) and it seems fine, its on the bubble, I probably default the other way, but std::function is complex and there are platforms where that kind of machine economy is a real consideration, so why not?

In a zillion contributor project I'd be a little more skeptical of the call, but even on massive projects like the Linux kernel they make decisions about the house style that seem unorthodox to outsiders and they have their reasons for doing so. I misplaced the link but a kernel maintainer raised grep-friendliness as a reason he didn't want a patch. At first I was like, nah you're not saying the real reason, but I looked a little and indeed, the new stuff would be harder to navigate without a super well-configured LSP.

Longtime maintainers have reasons they do things a certain way, and the real test is the result. In this instance (and in most) I think the maintainer seems to know what's best for their project.

How is Func0 / Func1<T> better than std::function?

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.

    res.fn = (void *)fn;

  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.

I did use bind earlier in SumatraPDF.

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.

> In fact, it has existed long before lambdas where introduced.

Both std::function<> and lambdas were introduced in C++11.

Furthermore absolutely no one should use std::bind, it's an absolute abomination.

    struct Foo {
        void bar(int a, int b, int c);
    };

    Foo foo;

    using Callback = std::function<void(int, int, int)>;

    // with std::bind (ugh):
    using namespace std::placeholders;
    Callback cb1(std::bind(&Foo::bar, &foo, _1, _2, _3));

    // lambda (without perfect forwarding):
    Callback cb2([&foo](auto&&... args) { foo.bar(args...); });

    // lambda (with perfect forwarding):
    Callback cb3([&foo](auto&&... args) { foo.bar(std::forward<decltype(args)>(args)...); });

    // std::bind_front
    Callback cb4(std::bind_front(&Foo::bar, &foo));

std::bind is bad for him for the same reasons std::function is bad though

I actually used the "virtual function" approach earlier in SumatraPDF.

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());

compared to:

    HANDLE StartThread(const Func0&, const char* threadName = nullptr);    
    auto fn = MkFunc0(InstallerThread, &gCliNew);
    StartThread(fn, "InstallerThread");

I would have to create a base class for every unique type of the callback and then for every caller possibly a new class deriving.

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.

    template<class R, class... Args>
    struct FnBase {
       virtual R operator()(Args...) = 0;
    };

    class MyThread : FnBase<void> { ... };

Better solution would be to map to a source location (filename and line) instead.

And another one dies every time you need to step through a call to std::function. Whatever you do, the kittens are never going to escape.

Unless you mutter the magic incantation "C compatibility" while doing it

did nullptr exist in c++ back in 1995 - i can't remember

Here's the GCC implementation of `std::function`:

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...

I'm with OP here.

I don't know fancy C++ so I don't understand your point about perfect forwarding.

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));
    }

Just use std::function, you don't have to pass a lambda. Any callable is fine.

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.

  - better call stacks in crash reports
  - smaller and faster at runtime
  - faster compilation because less complicated, less templated code
  - I understand it

    struct MyWindow { void onButtonClicked(); };

    // old-school: std::bind
    setCallback(std::bind(&MyWindow::onButtonClicked, window));

    // modern: a simple lambda
    setCallback([window]() { window->onButtonClicked(); });

It's back up now.

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.

For those not in the know:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...

Class is a set of functions. Closure is one function.

In old Java, it really was a class. In new Java, I'm not 100% sure anymore, but with verbose syntax it'll be an class. I made it as verbose as possible:

  Function<Integer, Integer> adder(int x) {
    class Adder implements Function<Integer, Integer> {
      int x1;
      @Override Integer apply(Integer y) {
        return x1 + y;
      }
    }

    Adder adder = new Adder();
    adder.x1 = x;
    return adder;
  }

and a bit less verbose with modern Java:

  Function<Integer, Integer> adder(int x) {
    return (y) -> x + y;
  }

So closure could be definitely be considered as a very simple class.

One, I didn't know about it.

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".

I'd be more sympathetic to your argument if this was about Python or Java web backends or something like that. But in C++, especially for a program like SumatraPDF with millions of installations on end-user computers where crashes can occur far away from a debugger, it's often borderline impossible to analyse problems without at least somewhat understanding the internals of every library feature you use.

I think avoiding features you don't understand the implementation of makes a lot of sense in those kinds of situations.

The hidden assumption in your comment is that the contract is implemented perfectly and that the abstraction isn't leaky. This isn't always the case. The author explained a concrete way in which the std::function abstraction leaks:

> They get non-descriptive, auto-generated names. When I look at call stack of a crash I can’t map the auto-generated closure name to a function in my code. It makes it harder to read crash reports.

    std::function<void()> cb([widget]() { widget->onButtonClicked(); });

    std::function<void()> cb(std::bind(&Widget::onButtonClicked, widget));

Programming requires making fine-grained implementation decisions.

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".

As opposed to?

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.