Almacenamiento de pila de objetos pequeños, reglas de alias estrictos y Comportamiento Indefinido

La mejor opción es utilizar la instalación estándar para el almacenamiento alineado para la creación de objetos, que se llama aligned_storage:

std::aligned_storage_t<64, sizeof(void*)> c;

// ...
new(&c) F(std::forward<F>(f));
reinterpret_cast<T*>(&c)->operator()();
reinterpret_cast<T*>(&c)->~T();

Ejemplo.

Si está disponible, debe usar std::launder para envolver sus reinterpret_casts: ¿Cuál es el propósito de std::launder?; si std::launder no está disponible, puede asumir que su compilador es pre-P0137 y las reinterpret_cast s son suficientes según la regla "puntos a" ( [basic.compuesto]/3). Puede probar std::launder usando #ifdef __cpp_lib_launder; ejemplo.

Dado que esta es una instalación Estándar, se le garantiza que si la usa de acuerdo con la descripción de la biblioteca (es decir, como se mencionó anteriormente), entonces no hay peligro de quemarse.

Como bonus, esto también asegurará que cualquier advertencia del compilador sea suprimida.

Un peligro no cubierto por la pregunta original es que estás fundiendo la dirección de almacenamiento a un tipo base polimórfico de tu tipo derivado. Esto solo está bien si se asegura de que el la base polimórfica tiene la misma dirección ( [ptr.lavandería]/1: "Un objeto X que está dentro de su vida [...] se encuentra en la dirección A") como el objeto completo en el momento de la construcción, ya que esto no está garantizado por el Estándar (ya que un tipo polimórfico no es estándar-diseño). Puedes comprobar esto con un assert:

    auto* p = new(&c) derived<F>(std::forward<F>(f));
    assert(static_cast<base*>(p) == std::launder(reinterpret_cast<base*>(&c)));

Sería más limpio usar herencia no polimórfica con una tabla v manual, como propone Yakk, ya que entonces la herencia será standard-layout y el subobjeto de la clase base tienen garantizada la misma dirección que el objeto completo.

Si observamos la implementación de aligned_storage, es equivalente a su alignas(sizeof(void*)) char c[64], solo envuelto en un struct, y de hecho gcc puede cerrarse envolviendo su char c[64] en un struct; aunque estrictamente hablando después de P0137 debe usar unsigned char en lugar de simplemente char. Sin embargo, este es un área de la Norma en rápida evolución, y esto podría cambiar en el futuro. Si utiliza el siempre tiene una mejor garantía de que va a seguir trabajando.

La otra respuesta es básicamente reconstruir lo que la mayoría de los compiladores hacen bajo el capó. Cuando se almacena el puntero devuelto por la colocación nueva, entonces no hay necesidad de construir manualmente vtables :

class Func{    
    struct base{
        virtual void operator()() = 0;
        virtual ~base(){}
    };

    template<typename T> struct derived : public base{
        derived(T&& t) : callable(std::move(t)) {} 
        void operator()() override{ callable(); }
        T callable;
    };

    std::aligned_storage_t<64 - sizeof(base *), sizeof(void *)> data;
    base * ptr;

public:
    Func() = delete;
    Func(const Func&) = delete;

    template<typename F> //SFINAE constraints skipped for brevity
    Func(F&& f){
        static_assert(sizeof(derived<F>) <= sizeof(data), "");
        ptr = new(static_cast<void *>(&data)) derived<F>(std::forward<F>(f));
    }

    void operator () (){
        return ptr->operator()();
    }

    ~Func(){
        ptr->~base();
    }
};

Va desde derived<T> * a base * es perfectamente válido (N4431 §4.10/3):

Un prvalue de tipo "puntero a cv D", donde D es un tipo de clase, se puede convertir en un prvalue de tipo " puntero a cv B", donde B es una clase base (Cláusula 10) de D. [..]

Y desde el las funciones miembro respectivas son virtuales, llamándolas a través del puntero base en realidad llama a las funciones respectivas en la clase derivada.