Comment by skrebbel

Comment by skrebbel 6 months ago

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.

spacechild1 6 months ago

> The author explained a concrete way in which the std::function abstraction leaks:

But that's not an issue with std::function at all! His comment is really about lambdas and I don't understand why he conflates these two. Just don't put the actual code in a lambda:

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

Here the code is in a method and the lambda is only used to bind an object to the method. If you are old-school, you can also do this with std::bind:

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

Reply View 0 replies