Comment les génériques sont-ils mis en œuvre?

C'est la question du point de vue interne du compilateur.

Je m'intéresse aux génériques, pas aux modèles (C ++), j'ai donc marqué la question avec C #. Pas Java, car AFAIK les génériques dans les deux langues diffèrent dans les implémentations.

Quand je regarde les langages sans génériques, c'est assez simple, vous pouvez valider la définition de classe, l'ajouter à la hiérarchie et c'est tout.

Mais que faire de la classe générique, et surtout comment gérer les références à celle-ci? Comment s'assurer que les champs statiques sont singuliers par instanciation (c'est-à-dire à chaque fois que les paramètres génériques sont résolus).

Disons que je vois un appel:

var x = new Foo<Bar>();

Dois-je ajouter une nouvelle Foo_Barclasse à la hiérarchie?

Mise à jour: Jusqu'à présent, je n'ai trouvé que 2 messages pertinents, mais même ils n'entrent pas dans les détails dans le sens "comment le faire par vous-même":

• http://www.jprl.com/Blog/archive/development/2007/Aug-31.html
• http://www.artima.com/intv/generics2.html

Comment s'assurer que les champs statiques sont singuliers par instanciation (c'est-à-dire à chaque fois que les paramètres génériques sont résolus).

Chaque instanciation générique a sa propre copie de la table de méthodes (nommée de manière confuse), qui est où les champs statiques sont stockés.

Disons que je vois un appel:

var x = new Foo<Bar>();

Dois-je ajouter une nouvelle Foo_Barclasse à la hiérarchie?

Je ne suis pas sûr qu'il soit utile de considérer la hiérarchie des classes comme une structure qui existe réellement au moment de l'exécution, c'est plus une construction logique.

Mais si vous considérez MethodTables, chacune avec un pointeur indirect sur sa classe de base, pour former cette hiérarchie, alors oui, cela ajoute une nouvelle classe à la hiérarchie.

Je vois là deux vraies questions concrètes. Vous voudrez probablement poser des questions connexes supplémentaires (en tant que question distincte avec un lien vers celui-ci) pour bien comprendre.

Comment les champs statiques reçoivent-ils des instances distinctes par instance générique?

Eh bien, pour les membres statiques qui ne sont pas liés aux paramètres de type générique, c'est assez facile (utilisez un dictionnaire mappé des paramètres génériques à la valeur).

Les membres (statiques ou non) liés aux paramètres de type peuvent être gérés via l'effacement de type. Utilisez simplement la contrainte la plus forte (souvent System.Object). Étant donné que les informations de type sont effacées après les vérifications de type du compilateur, cela signifie que les vérifications de type d'exécution ne seront pas nécessaires (bien que les conversions d'interface puissent toujours exister au moment de l'exécution).

Chaque instance générique apparaît-elle séparément dans la hiérarchie de types?

Pas dans les génériques .NET. La décision a été prise d'exclure l'héritage des paramètres de type, il s'avère donc que toutes les instances d'un générique occupent la même place dans la hiérarchie de types.

C'était probablement une bonne décision, car ne pas rechercher des noms dans une classe de base serait incroyablement surprenant.

Mais que faire de la classe générique, et surtout comment gérer les références à celle-ci?

La manière générale dans le frontal du compilateur est d'avoir deux sortes d'instances de type, le type générique ( List<T>) et un type générique lié ( List<Foo>). Le type générique définit quelles fonctions existent, quels champs et a des références de type générique partout où il Test utilisé. Le type générique lié contient une référence au type générique et un ensemble d'arguments de type. Cela contient suffisamment d'informations pour que vous puissiez ensuite générer un type concret, en remplaçant les références de type génériques par Fooou quels que soient les arguments de type. Ce type de distinction est important lorsque vous faites une inférence de type et que vous devez déduire List<T>par rapport à List<Foo>.

Au lieu de penser à des génériques comme des modèles (qui construisent directement diverses implémentations), il peut être utile de les considérer plutôt comme des constructeurs de types de langage fonctionnel (où les arguments génériques sont comme des arguments dans une fonction qui vous donne un type).

Quant au back-end, je ne sais pas vraiment. Tout mon travail avec les génériques a ciblé CIL comme backend, donc je pouvais les compiler dans les génériques pris en charge.