Comment compiler un décorateur - C ++, Python et sa propre implémentation. Partie 1

Cette série d'articles sera consacrée à la possibilité de créer un décorateur en C ++, les caractéristiques de leur travail en Python, et l'une des options pour implémenter cette fonctionnalité dans son propre langage compilé sera considérée, en utilisant l'approche générale pour créer des fermetures - conversion de fermeture et modernisation de l'arbre de syntaxe.

Décorateur en C ++

Tout a commencé avec le fait que mon ami VoidDruid a décidé d'écrire un petit compilateur en guise de diplôme, dont la caractéristique principale est les décorateurs. Même pendant la pré-défense, lorsqu'il a souligné tous les avantages de son approche, qui comprenait la modification de l'AST, je me suis demandé: est-il vraiment impossible de mettre en œuvre ces mêmes décorateurs dans le grand et puissant C ++ et de se passer de termes et d'approches compliqués? Sur ce sujet, je n'ai trouvé aucune approche simple et générale pour résoudre ce problème (à propos, je n'ai trouvé que des articles sur la mise en œuvre du modèle de conception), puis je me suis assis pour écrire mon propre décorateur.

Cependant, avant de passer à une description directe de mon implémentation, je voudrais parler un peu de la façon dont les lambdas et les fermetures en C ++ sont arrangés et quelle est la différence entre eux. Faites immédiatement une réserve que s'il n'y a aucune mention d'une norme spécifique, alors par défaut, je veux dire C ++ 20. En bref, les lambdas sont des fonctions anonymes et les fermetures sont des fonctions qui utilisent des objets de leur environnement. Ainsi, par exemple, à partir de C ++ 11, un lambda peut être déclaré et appelé comme ceci:

int main() 
{
    [] (int a) 
    {
        std::cout << a << std::endl;
    }(10);
}

int main() 
{
    auto lambda = [] (int a) 
    {
        std::cout << a << std::endl;
    };
    lambda(10);
}

class __lambda_60_19
{
public: 
    inline void operator()(int a) const
    {
        std::cout.operator<<(a).operator<<(std::endl);
    }
    
    using retType_60_19 = void (*)(int);
    inline operator retType_60_19 () const noexcept
    {
        return __invoke;
    };
    
private: 
    static inline void __invoke(int a)
    {
        std::cout.operator<<(a).operator<<(std::endl);
    }    
};

void (*p_lambda) (int) = lambda;
p_lambda(10);

int main()
{
    int a = 10;
    auto closure = [&a] () { a += 1; };
    closure();
}

class __lambda_61_20
{
public:
    inline void operator()()
    {
        a += 1;
    }
private:
    int & a;
public:
    __lambda_61_20(int & _a)
    : a{_a}
    {}
};

Comme vous pouvez le voir, nous avons ajouté un nouveau constructeur non par défaut qui prend notre paramètre par référence et l'enregistre en tant que membre de la classe. En fait, c'est pourquoi vous devez être extrêmement prudent lorsque vous définissez [&] ou [=], car tout le contexte sera stocké dans la fermeture, et cela peut être assez sous-optimal de la mémoire. De plus, nous avons perdu l'opérateur de transtypage en un pointeur de fonction, car maintenant, pour son contexte d'appel normal, il est nécessaire. Et maintenant, le code ci-dessus ne se compilera pas:

int main()
{
    int a = 10;
    auto closure = [&a] () { a += 1; };
    closure();
    void (*ptr)(int) = closure;
}

std::function<void()> function = closure;
function();

namespace Decorator
{
    template<typename R, typename ...Args>
    static auto make(const std::function<R(Args...)>& f)
    {
        std::cout << "Do something" << std::endl;
        return [=](Args... args) 
        {
            return f(std::forward<Args>(args)...);
        };
    }
};

void myFunc(int a)
{
    std::cout << "here" << std::endl;
}

int main()
{
    std::function<void(int)> f = myFunc;
    auto decorated = Decorator::make(f);
    decorated(10);
}

1. Ce code ne peut être compilé qu'avec les versions C ++ 14 et supérieures, car il n'est pas possible de connaître le type retourné à l'avance. Malheureusement, je dois vivre avec cela et je n'ai pas trouvé d'autres options.
2. make requiert que std :: function lui soit passé, et passer une fonction par son nom conduit à des erreurs de compilation. Et ce n'est pas du tout aussi pratique que nous le souhaiterions! Nous ne pouvons pas écrire de code comme ceci:
   
   

   Decorator::make([](){});
   Decorator::make(myFunc);
   void(*ptr)(int) = myFunc;
   Decorator::make(ptr);

   
   
3. De plus, il n'est pas possible de décorer une méthode de classe.
   

namespace Decorator
{
    template<typename Function>
    static auto make(Function&& func)
    {
        return [func = std::forward<Function>(func)] (auto && ...args) 
        {
            std::cout << "Do something" << std::endl;
            return std::invoke(
                func,
                std::forward<decltype(args)>(args)...
            );
        };
    }
};

int main()
{
    auto decorated_1 = Decorator::make(myFunc);
    decorated_1(1,2);

    auto my_lambda = [] (int a, int b) 
    { 
        std::cout << a << " " << b <<std::endl; 
    };
    auto decorated_2 = Decorator::make(my_lambda);
    decorated_2(3,4);

    int (*ptr)(int, int) = myFunc;
    auto decorated_3 = Decorator::make(ptr);
    decorated_3(5,6);

    std::function<void(int, int)> fun = myFunc;
    auto decorated_4 = Decorator::make(fun);
    decorated_4(7,8);

    auto decorated_5 = Decorator::make(decorated_4);
    decorated_5(9, 10);

    auto decorated_6 = Decorator::make(&MyClass::func);
    decorated_6(MyClass(10));
}

namespace Decorator
{
    template<typename Function>
    static auto make(Function&& func)
    {
        return [func = std::forward<Function>(func)] 
        <typename ...Args> (Args && ...args) 
        {
            return std::invoke(
                func,
                std::forward<Args>(args)...
            );
        };
    }
};