История изменений

Возможно я неправильно понял твою идею с использованием виртуального метода.

Очевидно, что так.

В TaskBase можно иметь просто виртуальный метод invoke:

class TaskBase {
protected:
  TaskBase() = default;

public:
  virtual ~TaskBase() = default;

  virtual void invoke() = 0;
};

А в наследниках просто переопределять этот invoke:

template<typename Handler>
class Task : public TaskBase {
  Handler fn_;
public:
  template<typename Fn>
  Task(Fn && fn) : fn_{std::forward<Fn>(fn)} {}

  void invoke() override { fn_(); }
};

Зачем все эти приседания с указателем на функцию, дополнительные статические методы со static_cast внутри?

Ну и еще вам в TaskBase, скорее всего, потребуется виртуальный деструктор.

Возможно. Зависит от имплементации.

Зависит от имплементации очереди тасков. Т.к. если вы будете хранить unique_ptr<TaskBase>, то проблемы из-за отсутствия виртуального деструктора практически гарантированы.

Если же будет использоваться shared_ptr<TaskBase>, то подобных проблем можно избежать. Но это зависит от кривизны рук программиста.

Так что лучше сделать виртуальный деструктор. А отказаться от него только если профайлер покажет, что есть просадка производительности из-за этого виртуального вызова (что вряд ли будет иметь место в 99% случаев).

Возможно я неправильно понял твою идею с использованием виртуального метода.

Очевидно, что так.

В TaskBase можно иметь просто виртуальный метод invoke:

class TaskBase {
protected:
  TaskBase() = default;

public:
  virtual ~TaskBase() = default;

  virtual void invoke() = 0;
};

А в наследниках просто переопределять этот invoke:

template<typename Handler>
class Task : public TaskBase {
  Handler fn_;
public:
  template<typename Fn>
  Task(Fn && fn) : fn_{std::forward<Fn>(fn)} {}

  void invoke() override { fn_(); }
};

Зачем все эти приседания с указателем на функцию, дополнительные статические методы со static_cast внутри?

Ну и еще вам в TaskBase, скорее всего, потребуется виртуальный деструктор.

Возможно. Зависит от имплементации.

Зависит от имплементации очереди сообщений. Т.к. если вы будете хранить unique_ptr<TaskBase>, то проблемы из-за отсутствия виртуального деструктора практически гарантированы.

Если же будет использоваться shared_ptr<TaskBase>, то подобных проблем можно избежать. Но это зависит от кривизны рук программиста.

Так что лучше сделать виртуальный деструктор. А отказаться от него только если профайлер покажет, что есть просадка производительности из-за этого виртуального вызова (что вряд ли будет иметь место в 99% случаев).