💥 Redo all higher order template functions

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).
This commit is contained in:
Robbert van der Helm
2021-05-20 00:53:48 +02:00
parent 6c58f4e305
commit e4ca520b64
11 changed files with 91 additions and 93 deletions
@@ -136,12 +136,11 @@ class Vst3PlugViewProxyImpl : public Vst3PlugViewProxy {
* right now.
*
* @see Vst3HostBridge::send_mutually_recursive_message
*
* TODO: As mentioned elsewhere, refactor these functions to use
* `std::invoke_result_t`
*/
template <typename T, typename F>
T run_gui_task(F fn) {
template <std::invocable F>
std::invoke_result_t<F> run_gui_task(F&& fn) {
using Result = std::invoke_result_t<F>;
// If `Vst3Bridge::send_mutually_recursive_message()` is currently being
// called (because the host is calling one of `IPlugView`'s methods from
// its UGI thread), then we'll call `fn` from that same thread.
@@ -154,8 +153,8 @@ class Vst3PlugViewProxyImpl : public Vst3PlugViewProxy {
}
if (run_loop_tasks) {
std::packaged_task<T()> do_call(std::move(fn));
std::future<T> do_call_response = do_call.get_future();
std::packaged_task<Result()> do_call(std::forward<F>(fn));
std::future<Result> do_call_response = do_call.get_future();
run_loop_tasks->schedule(std::move(do_call));