Replace std::function with a faster implementation

[Dawoodoz]

The goal is to prevent unexpected heap allocations that ruin performance, and call heap.h when a heap allocation is actually needed, so that memory leaks can be detected without needing external tools.

Might be possible to implement a system with multiple interoperable types of lambdas using static inheritance. The temporary lambda type given to functions contains the function pointer and a pointer to captured data. Storable lambdas are abstract and inherit from temporary lambdas and implements copy, move and assignment operations with reference counting to any heap allocation.

[Dawoodoz]

Maybe this can wait until after 0.3.0, now that the code is quite stable with the new memory system. Version 0.3.0 is already quite delayed.

[Dawoodoz]

Observability
On top of better detection of memory leaks by using the custom memory allocator, a custom implementation can also allow debug builds to get a debug name of the assigned function to simplify debugging of what is otherwise a black box saying nothing about its content.

Safety
Choosing between nullable and non-nullable function types with explicit failure handling during casts from nullable, could improve safety by requiring that non-nullable function types are always assigned something that can be called without checking if it exists.

[Dawoodoz]

This needs to be done before version 1.0, so that there are no unpredictable std types in the interface.

To maintain backward compatibility in rare edge cases, one would however need a standard template to start from before carefully improving the functionality. The standard library implementations are full of hardcoded hacks specific to a single compiler that would never work across compilers, so the external interface can not be based on them. Ideally, the upgrade away from std::function should be an automatic text replacement on all files at once.

[Dawoodoz]

Trying an alias in the experimental branch, so that std::function can be referred to as dsr::Callable instead of relying on the std namespace directly in the APIs.

[Dawoodoz]

For multi-threading, Callback can be used for jobs in the interface, while std::function is used internally for worker threads together with std::future, to avoid having to create native backends for multi-threading.

[Dawoodoz]

When first creating a Callback from a lambda, it should simply point to the stack allocated data and know its size. Once assigned to another Callback copying it by value, it should heap allocate a copy of the lambda with enough alignment and start reference counting. Assigning it by value again, should simply increase the allocation's reference count.

If one can simply keep track on when dynamic memory allocations are being made, the costs can be reduced significantly using a system of optional warnings, maybe one stack allocated Callback that may not outlive the scope where it was created, one fixed size Callback that has a specified size limit on capture, and one heap allocated Callback that can be saved for later no matter which size it has.

Capture with strict alignment requirements might be difficult to store efficiently within a fixed size container, due to arbitrary alignment requirements.

Variables captured by reference should probably not be allowed for callbacks that can be assigned by value for later use.

[Dawoodoz]

Created a separate project for testing my experimental implementation in isolation, so that it can pass basic test cases before handling complicated edge cases. Began with a basic wrapper around std::function, just to check that the interface itself works. Once the wrapper has enough of the essential functionality, the real work of implementing storage for the arbitrary lambda types given on construction can begin.

[Dawoodoz]

Created a callback type that guarantees that no heap allocations will be made, but can only be used as an input argument, because it points directly to the lambda's closure in the stack and an automatically generated invoke function. By placing the error message for calling a null function into a default invocation function, there is no need to check if the function pointer is null for every call. The only use of std is std::forward for passing arguments to the functions, which is as tightly coupled with the core language as std::move.

Then we need a preserving callback type that can be called at any time. It will need all members of the closure to be copy-constructible, so that an in-place construction can copy the closure to heap memory. A preserving callback should not allow the closure to contain references to stack memory that might not exist when called. The closure's destructor will have to be passed to the allocator, so that there will be no memory leaks when capturing reference counted handles for a lambda.

The difficult part will be where to break the cycle of implicit construction when having more than one type of callback to convert back and forth. So all the types of callbacks might have to be merged into a single type but use an explicit cloning call when it is allowed to heap allocate a closure when one exists. A bit flag in the callback from construction can then be allocated in debug mode and assert that variables captured by reference are not preserved for later use when cloning it to heap memory.