I once read years ago somewhere on Stack Overflow that `std::vectors`
with that are preinitialized to a default size would allocate the
initial capacity on the stack. This of course doesn't make any
sense (run time sized stack allocations can cause all kinds of issues),
so we were still allocating with our default 64-byte sized buffers, but
just not as often.
This does what we did for a few functions in the last few commits for
every function. We now use either the `std::invocable` concept or our
own `invocable_returning` concept wherever possible to make sure we pass
function types to these template functions, since constraint errors are
a lot more readable than template deduction errors. And instead of
having to specify the return type as a template argument, we now just
use `std::invoke_result_t<F>` instead. The VST3 message handling
functions are still using the good old `typename F` since those are
overloaded polymorphic functions. This was also a good moment to modify
`AdHocSocketHandler::send()` to allow functions returning void (this got
rid of an old fixme where we had to return some dummy value from a
function instead of just not returning anything).
Apparently this can actually make a difference in some cases, and the
C++ Core Guideliens recommend doing this on all default constructors,
destructors, and all functions that can not throw (and thus also don't
allocate).
We would close the socket, but the `receive_multi()` call would finish
after the object had already been deallocated using `erase()`. Somehow
this never caused any issues though.
If `yabridge-host.exe` were somehow to be run with a socket base
directory that's not inside of `$XDG_RUNTIME_DIR`/`/tmp`, then we'll now
warn instead of removing that directory. This should not be necessary,
but in case someone wants to write a wrapper around
`yabridge-host.exe.so` us using a custom `$WINELOADER` then this could
save a lot of headaches.
It turns out we can't safely disable this, because in some situations we
still have these mutually recursive function calls. We could optimize
this a bit to have those calls be handled by the general sockets, but
this is much more manageable.
This reverts commit 415c1b5683.
This way every relevant object instance will get its own thread for
handling these calls. The alternative would be creating a full fat
Vst3MessageHandler pair for all object instances, but that would be a
huge waste.
We'll need this for handling `IAudioProcessor` method calls in VST3. We
basically want a `Vst3MessageHandler` per `IAudioProcessor` instance,
but without the additional socket spawning or extra thread.
We're going to need this for VST3 because we're going to have to
explicitly instantiate our interface implementations since they need to
be able to perform complicated callbacks.
Robbert van der Helm