Les modèles C++ sont-ils des macros déguisées ?

Question

Je programme en C++ depuis quelques années, j'ai utilisé STL assez souvent et j'ai créé mes propres classes de modèles à plusieurs reprises pour voir comment cela se passait.

Aujourd'hui, j'essaie d'intégrer davantage les modèles dans ma conception OO, et une pensée tenace me revient sans cesse à l'esprit : Ce ne sont que des macros, en fait... Vous pourriez implémenter des auto_ptrs (plutôt UGLY) en utilisant des #defines, si vous le vouliez vraiment.

Cette façon de concevoir les modèles m'aide à comprendre comment mon code fonctionnera réellement, mais j'ai l'impression que je ne comprends pas ce que je veux dire. Les macros sont le mal incarné, mais la "métaprogrammation de modèles" fait fureur.

Alors, quelles sont les vraies distinctions ? et comment les modèles peuvent-ils éviter les dangers que #define vous fait courir, comme par exemple

• Erreurs de compilation dans là où l'on ne s'y attend pas ?
• Le gonflement du code ?
• Difficultés de traçage du code ?
• Définir les points d'arrêt du débogueur ?

Answer 1

Les macros sont un mécanisme de substitution de texte.

Les modèles sont un langage fonctionnel complet qui est exécuté au moment de la compilation et qui est intégré dans le système de type C++. On peut les considérer comme un mécanisme d'extension du langage.

Answer 2

Ils sont analysés par l'outil compilateur et non par un préprocesseur qui exécute avant le compilateur.

Voici ce que dit MSDN à ce sujet : http://msdn.microsoft.com/en-us/library/aa903548(VS.71).aspx

Voici quelques problèmes liés à la macro :

• Le compilateur n'a aucun moyen de vérifier que les paramètres des macros sont de types compatibles.
• La macro est développée sans vérification particulière du type.
• Les paramètres i et j sont évalués deux fois. Par exemple, si l'un des paramètres a une variable postincrémentée, l'incrémentation est effectuée deux fois.
• Les macros étant développées par le préprocesseur, les messages d'erreur du compilateur feront référence à la macro développée plutôt qu'à la définition de la macro elle-même. En outre, la macro apparaîtra sous sa forme développée lors du débogage.

Si cela ne vous suffit pas, je ne sais pas ce que c'est.

Answer 3

De nombreux commentaires tentent de différencier les macros et les modèles.

Oui, il s'agit de la même chose : des outils de génération de code.

Les macros sont une forme primitive, sans beaucoup d'application de la part du compilateur (comme faire des objets en C - c'est possible, mais ce n'est pas joli). Les modèles sont plus avancés, et disposent d'un meilleur contrôle de type du compilateur, de messages d'erreur, etc.

Cependant, chacun possède des atouts que l'autre n'a pas.

Les modèles ne peuvent générer que des types de classes dynamiques, alors que les macros peuvent générer presque n'importe quel code (autre qu'une autre définition de macro). Les macros peuvent être très utiles pour intégrer des tableaux statiques de données structurées dans votre code.

Les modèles, quant à eux, permettent d'accomplir des choses vraiment FUNKY qui ne sont pas possibles avec les macros. Par exemple :

template<int d,int t> class Unit
{
    double value;
public:
    Unit(double n)
    {
        value = n;
    }
    Unit<d,t> operator+(Unit<d,t> n)
    {
        return Unit<d,t>(value + n.value);
    }
    Unit<d,t> operator-(Unit<d,t> n)
    {
        return Unit<d,t>(value - n.value);
    }
    Unit<d,t> operator*(double n)
    {
        return Unit<d,t>(value * n);
    }
    Unit<d,t> operator/(double n)
    {
        return Unit<d,t>(value / n);
    }
    Unit<d+d2,t+t2> operator*(Unit<d2,t2> n)
    {
        return Unit<d+d2,t+t2>(value * n.value);
    }
    Unit<d-d2,t-t2> operator/(Unit<d2,t2> n)
    {
        return Unit<d-d2,t-t2>(value / n.value);
    }
    etc....
};

#define Distance Unit<1,0>
#define Time     Unit<0,1>
#define Second   Time(1.0)
#define Meter    Distance(1.0)

void foo()
{
   Distance moved1 = 5 * Meter;
   Distance moved2 = 10 * Meter;
   Time time1 = 10 * Second;
   Time time2 = 20 * Second;
   if ((moved1 / time1) == (moved2 / time2))
       printf("Same speed!");
}

Le modèle permet au compilateur de créer et d'utiliser dynamiquement, à la volée, des instances de modèle sûres du point de vue du type. Le compilateur effectue en fait le calcul des paramètres du modèle au moment de la compilation, en créant des classes distinctes si nécessaire pour chaque résultat unique. Il existe un type implicite Unit<1,-1> (distance / temps = vitesse) qui est créé et comparé dans le conditionnel, mais qui n'est jamais explicitement déclaré dans le code.

Apparemment, quelqu'un dans une université a défini un modèle de ce type avec plus de 40 paramètres (besoin d'une référence), chacun représentant un type d'unité de physique différent. Pensez à la sécurité de type de ce type de classe, juste pour vos chiffres.

Answer 4

La réponse est tellement longue que je ne peux pas tout résumer :

• par exemple, les macros ne garantissent pas la sécurité des types, alors que les modèles de fonctions le font :
  Le compilateur n'a aucun moyen de vérifier que les paramètres de la macro sont de types compatibles -- au moment où le modèle de fonction est instancié, le compilateur sait également si int o float définir operator +
• Les modèles ouvrent la porte à la métaprogrammation (en bref, évaluer les choses et prendre des décisions au moment de la compilation) :
  Au moment de la compilation, il est possible de savoir si un type est intégral ou à virgule flottante, s'il s'agit d'un pointeur ou d'une constante qualifiée, etc... voir les "traits de type" dans la prochaine version de c++0x .
• les modèles de classe ont une spécialisation partielle
• les modèles de fonctions ont une spécialisation complète explicite, dans votre exemple add<float>(5, 3); pourrait être mis en œuvre différemment de add<int>(5, 3); ce qui n'est pas possible avec les macros
• les macros n'ont pas de portée
• #define min(i, j) (((i) < (j)) ? (i) : (j)) - les i y j sont évalués deux fois. Par exemple, si l'un des paramètres a une variable postincrémentée, l'incrémentation est effectuée deux fois
• les macros étant développées par le préprocesseur, les messages d'erreur du compilateur feront référence à la macro développée plutôt qu'à la définition de la macro elle-même. De plus, la macro apparaîtra sous sa forme développée lors du débogage
• etc...

Note : Dans certains cas rares, j'ai préféré m'appuyer sur des macros variadiques car les modèles variadiques n'existent pas jusqu'à ce que le c++0x devienne courant. C++11 est en direct.

Références :

• C++ FAQ Lite : [35] Modèles
• Avantages des modèles (retraité, peut être téléchargé)
• Modèles et macros (C++) (retraité, peut être téléchargé)

Answer 5

Au niveau le plus élémentaire, oui, les modèles sont simplement des remplacements de macro. Mais vous faites l'impasse sur beaucoup des choses en y réfléchissant de cette manière.

Pensez à la spécialisation des modèles, qui, à ma connaissance, ne peut pas être simulée par des macros. Non seulement cela permet une implémentation spéciale pour certains types, mais c'est aussi l'un des éléments clés de la métaprogrammation des modèles :

template <typename T>
struct is_void
{
    static const bool value = false;
}

template <>
struct is_void<void>
{
    static const bool value = true;
}

Ce qui, en soi, n'est qu'un exemple de la beaucoup de choses que vous pouvez faire . Les modèles eux-mêmes sont Turing-complets.

Cela ne tient pas compte des éléments fondamentaux, tels que la portée, la sécurité des types et le fait que les macros sont plus compliquées.