Comment std :: function est-il implémenté?

Selon les sources que j'ai trouvées, une expression lambda est essentiellement implémentée par le compilateur créant une classe avec un opérateur d'appel de fonction surchargé et les variables référencées en tant que membres. Cela suggère que la taille des expressions lambda varie et que, compte tenu de suffisamment de variables de référence, la taille peut être arbitrairement grande .

Un std::functiondevrait avoir une taille fixe , mais il doit être capable d'encapsuler n'importe quel type de callable, y compris n'importe quel lambdas du même type. Comment est-il mis en œuvre? Si std::functionutilise en interne un pointeur vers sa cible, que se passe-t-il lorsque l' std::functioninstance est copiée ou déplacée? Y a-t-il des allocations de tas impliquées?

L'implémentation de std::functionpeut différer d'une implémentation à l'autre, mais l'idée de base est qu'elle utilise l'effacement de type. Bien qu'il existe plusieurs façons de le faire, vous pouvez imaginer qu'une solution triviale (non optimale) pourrait être comme celle-ci (simplifiée pour le cas spécifique de std::function<int (double)>par souci de simplicité):

struct callable_base {
   virtual int operator()(double d) = 0;
   virtual ~callable_base() {}
};
template <typename F>
struct callable : callable_base {
   F functor;
   callable(F functor) : functor(functor) {}
   virtual int operator()(double d) { return functor(d); }
};
class function_int_double {
   std::unique_ptr<callable_base> c;
public:
   template <typename F>
   function(F f) {
      c.reset(new callable<F>(f));
   }
   int operator()(double d) { return c(d); }
// ...
};

Dans cette approche simple, l' functionobjet stockerait uniquement un unique_ptrtype de base. Pour chaque foncteur différent utilisé avec le function, un nouveau type dérivé de la base est créé et un objet de ce type instancié dynamiquement. L' std::functionobjet est toujours de la même taille et allouera de l'espace selon les besoins pour les différents foncteurs du tas.

Dans la vraie vie, il existe différentes optimisations qui offrent des avantages en termes de performances mais compliqueraient la réponse. Le type pourrait utiliser des optimisations de petits objets, la répartition dynamique peut être remplacée par un pointeur de fonction libre qui prend le foncteur comme argument pour éviter un niveau d'indirection ... mais l'idée est fondamentalement la même.

Concernant la question de savoir comment les copies std::function comportement des comportement, un test rapide indique que des copies de l'objet appelable interne sont effectuées, plutôt que de partager l'état.

// g++4.8
int main() {
   int value = 5;
   typedef std::function<void()> fun;
   fun f1 = [=]() mutable { std::cout << value++ << '\n' };
   fun f2 = f1;
   f1();                    // prints 5
   fun f3 = f1;
   f2();                    // prints 5
   f3();                    // prints 6 (copy after first increment)
}

Le test indique qu'il f2obtient une copie de l'entité appelable, plutôt qu'une référence. Si l'entité appelable était partagée par les différents std::function<>objets, la sortie du programme aurait été 5, 6, 7.

La réponse de @David Rodríguez - dribeas est bonne pour démontrer l'effacement de type mais pas assez car l'effacement de type inclut également la manière dont les types sont copiés (dans cette réponse, l'objet fonction ne sera pas constructible par copie). Ces comportements sont également stockés dans lefunction objet, en plus des données du foncteur.

L'astuce, utilisée dans l'implémentation STL d'Ubuntu 14.04 gcc 4.8, consiste à écrire une fonction générique, à la spécialiser avec chaque type de foncteur possible et à les convertir en un type de pointeur de fonction universel. Par conséquent, les informations de type sont effacées .

J'ai bricolé une version simplifiée de cela. J'espère que ça aidera

#include <iostream>
#include <memory>

template <typename T>
class function;

template <typename R, typename... Args>
class function<R(Args...)>
{
    // function pointer types for the type-erasure behaviors
    // all these char* parameters are actually casted from some functor type
    typedef R (*invoke_fn_t)(char*, Args&&...);
    typedef void (*construct_fn_t)(char*, char*);
    typedef void (*destroy_fn_t)(char*);

    // type-aware generic functions for invoking
    // the specialization of these functions won't be capable with
    //   the above function pointer types, so we need some cast
    template <typename Functor>
    static R invoke_fn(Functor* fn, Args&&... args)
    {
        return (*fn)(std::forward<Args>(args)...);
    }

    template <typename Functor>
    static void construct_fn(Functor* construct_dst, Functor* construct_src)
    {
        // the functor type must be copy-constructible
        new (construct_dst) Functor(*construct_src);
    }

    template <typename Functor>
    static void destroy_fn(Functor* f)
    {
        f->~Functor();
    }

    // these pointers are storing behaviors
    invoke_fn_t invoke_f;
    construct_fn_t construct_f;
    destroy_fn_t destroy_f;

    // erase the type of any functor and store it into a char*
    // so the storage size should be obtained as well
    std::unique_ptr<char[]> data_ptr;
    size_t data_size;
public:
    function()
        : invoke_f(nullptr)
        , construct_f(nullptr)
        , destroy_f(nullptr)
        , data_ptr(nullptr)
        , data_size(0)
    {}

    // construct from any functor type
    template <typename Functor>
    function(Functor f)
        // specialize functions and erase their type info by casting
        : invoke_f(reinterpret_cast<invoke_fn_t>(invoke_fn<Functor>))
        , construct_f(reinterpret_cast<construct_fn_t>(construct_fn<Functor>))
        , destroy_f(reinterpret_cast<destroy_fn_t>(destroy_fn<Functor>))
        , data_ptr(new char[sizeof(Functor)])
        , data_size(sizeof(Functor))
    {
        // copy the functor to internal storage
        this->construct_f(this->data_ptr.get(), reinterpret_cast<char*>(&f));
    }

    // copy constructor
    function(function const& rhs)
        : invoke_f(rhs.invoke_f)
        , construct_f(rhs.construct_f)
        , destroy_f(rhs.destroy_f)
        , data_size(rhs.data_size)
    {
        if (this->invoke_f) {
            // when the source is not a null function, copy its internal functor
            this->data_ptr.reset(new char[this->data_size]);
            this->construct_f(this->data_ptr.get(), rhs.data_ptr.get());
        }
    }

    ~function()
    {
        if (data_ptr != nullptr) {
            this->destroy_f(this->data_ptr.get());
        }
    }

    // other constructors, from nullptr, from function pointers

    R operator()(Args&&... args)
    {
        return this->invoke_f(this->data_ptr.get(), std::forward<Args>(args)...);
    }
};

// examples
int main()
{
    int i = 0;
    auto fn = [i](std::string const& s) mutable
    {
        std::cout << ++i << ". " << s << std::endl;
    };
    fn("first");                                   // 1. first
    fn("second");                                  // 2. second

    // construct from lambda
    ::function<void(std::string const&)> f(fn);
    f("third");                                    // 3. third

    // copy from another function
    ::function<void(std::string const&)> g(f);
    f("forth - f");                                // 4. forth - f
    g("forth - g");                                // 4. forth - g

    // capture and copy non-trivial types like std::string
    std::string x("xxxx");
    ::function<void()> h([x]() { std::cout << x << std::endl; });
    h();

    ::function<void()> k(h);
    k();
    return 0;
}

Il y a aussi quelques optimisations dans la version STL

• le construct_fetdestroy_f sont mélangés en un pointeur de fonction (avec un paramètre supplémentaire qui dit quoi faire) comme pour sauver quelques octets
• les pointeurs bruts sont utilisés pour stocker l'objet foncteur, avec un pointeur de fonction dans un union , de sorte que lorsqu'un functionobjet est construit à partir d'un pointeur de fonction, il sera stocké directement dans l' unionespace plutôt que dans l' espace du tas

Peut-être que l'implémentation STL n'est pas la meilleure solution car j'ai entendu parler d'une implémentation plus rapide . Cependant, je pense que le mécanisme sous-jacent est le même.

Pour certains types d'arguments ("si la cible de f est un objet appelable passé via reference_wrapperou un pointeur de fonction"), std::functionle constructeur de n'autorise aucune exception, donc l'utilisation de la mémoire dynamique est hors de question. Dans ce cas, toutes les données doivent être stockées directement dans lestd::function objet.

Dans le cas général (y compris le cas lambda), l'utilisation de la mémoire dynamique (via l'allocateur standard ou un allocateur passé au std::functionconstructeur) est autorisée comme l'implémentation le juge opportun. Le standard recommande que les implémentations n'utilisent pas de mémoire dynamique si cela peut être évité, mais comme vous le dites à juste titre, si l'objet fonction (pas l' std::functionobjet, mais l'objet qui est enveloppé à l'intérieur) est suffisamment grand, il n'y a aucun moyen de l'empêcher, puisquestd::function a une taille fixe.

Cette autorisation de lever des exceptions est accordée à la fois au constructeur normal et au constructeur de copie, ce qui autorise assez explicitement les allocations de mémoire dynamique pendant la copie. Pour les mouvements, il n'y a aucune raison pour laquelle la mémoire dynamique serait nécessaire. La norme ne semble pas l'interdire explicitement, et ne le peut probablement pas si le déplacement peut appeler le constructeur de déplacement du type de l'objet encapsulé, mais vous devriez pouvoir supposer que si l'implémentation et vos objets sont sensés, le déplacement ne provoquera pas toutes allocations.

An std::functionsurcharge le operator()fait d'en faire un objet foncteur, les lambda fonctionnent de la même manière. Il crée essentiellement une structure avec des variables membres accessibles à l'intérieur de la operator()fonction. Donc, le concept de base à garder à l'esprit est qu'un lambda est un objet (appelé foncteur ou objet fonction) et non une fonction. La norme dit de ne pas utiliser de mémoire dynamique si cela peut être évité.