CppCon 2018: Tom Poole “Why and How to Roll Your Own std::function Implementation”

—
—
In recent years the increased usage of std::function has transformed the way many C++ programs are written. However, if your application is processing realtime data, or doing some other performance critical task, then the possibility of std::function allocating some memory from the heap may not be tolerable. It's also possible that the systems you are targeting simply lack a std::function implementation, preventing its adoption in applications for legacy operating systems, toolchains for embedded devices, and inside open source library code. Rolling your own implementation of std::function can provide a solution to both of these concerns simultaneously, allowing you to modernize your code and provide guarantees about the runtime performance of manipulating function objects.

This presentation outlines why and how a std::function replacement was added to the JUCE open source, cross platform, software development framework and discusses some differences between our implementation and others. We will also cover how we can move beyond the standard interface by extending the small buffer optimization to make manipulating callable objects more suitable for performance critical and realtime contexts, finishing with some examples of how this applies to processing live audio data.
—
Tom Poole, ROLI
Senior Software Developer

—

*-----*
*-----*

[mapron]

For supporting old MacOS < 10.7, we just backported libc++ to 10.6 and shipped it with our app. So, when we dropped that support, we still had standard C++ code.
So, if you using only few features from STL, it's not worth it to use alt implementation.

[-taz-]

1:15 I think a type of callable might be missing: member function offsets, as can be made callable with std::bind(&X::member_function_name, &X_instance, ...).

[Mirality]

One problem with the polymorphic designs is that if you want a collection of the type-erased versions then you have to make a collection of polymorphic pointers/references, which ends up either pushing you back to unique_ptr or otherwise having to worry about memory management, and that's a bit of a step backwards from the direction the libraries are trying to take nowadays.

The idea of making a std::function replacement with only SBO and no allocation is an interesting one though. Have you considered making the stack size itself a template parameter, so that the containing class can decide case-by-case how much storage to set aside for its typical users?

Otherwise yes, taking a callable as a templated parameter is the most efficient, but it's only possible when you have implementation in the header file, which inflates compilation times. And it's really awkward to try to constrain parameter types, although perhaps when Concepts finally land they might help with this.

[anon_y_mousse]

Am I going blind or are the materials for this talk not on the github page for 2018?