6
votes

Comment les modèles fonctionnent-ils, sont-ils toujours inlinés?

Je peux comprendre comment cela fonctionne si elles sont inlinées. Mais s'ils ne le sont pas, comment ça marche? Est-ce que tous les fichiers d'objet obtiennent leur propre copie de par exemple le modèle de fonction quand même?


1 commentaires

Les modèles sont pour la génération de code. Si vous utilisez un modèle, une classe / une fonction est générée et utilisée. Le compilateur peut supprimer plusieurs instances de modèles avec les mêmes paramètres, mais il n'est pas garanti. Je ne vois pas le lien à l'allusion.


6 Réponses :


1
votes

Il est dépendant de la mise en œuvre.

Mais commononly, oui, chaque fichier d'objet reçoit une copie de chaque fonction élargie qu'elles utilisent. Et ensuite, le lieur remarque cela au moment de la liaison et garantit qu'une seule copie de la fonction est placée dans le fichier exécutable final


0 commentaires

2
votes

dépend du compilateur, mais tout le monde que j'ai regardé crée une fonction qui soit appelable à l'aide des paramètres de modèle substitués pour générer le code de chaque variante.

comme (très) exemple simple: P > xxx pré>

lorsqu'il est invoqué comme max code> et max code> et non inliné, le compilateur génère (ils sont décorés dans Cependant, une manière particulière d'empêcher d'autres problèmes): P>

int Max(int a, int b)
{
    return a > b ? a : b;
}

float Max(float a, float b)
{
    return a > b ? a : b;
}


0 commentaires

2
votes

Cela dépend. Certaines des implémentations les plus populaires font Générez une copie du code d'instanciation dans chaque fichier d'objet qui déclenche une instanciation et comptez sur la liaison à jeter tout sauf un. D'autres compilateurs utilisent une sorte de référentiel, où les instanciations sont stockées; si la L'instanciation est déjà présente, le compilateur ne se dérange pas régénérer cela. Cette solution est significativement plus rapide et utilise moins de disque que la première solution, mais c'est aussi beaucoup plus difficile à obtenir raison. (Le compilateur doit générer une nouvelle instanciation non seulement si on n'est pas présent, mais si l'un des fichiers le L'instanciation dépend d'avoir changé.)


0 commentaires

4
votes

Les modèles seront inlinés dans la signification standard de en ligne , qui est plus lié à la règle d'une définition qu'à l'allusion actuelle du code. C'est-à-dire que la liaison ne se plaingera pas si les fonctions de modèle sont définies dans plusieurs unités de traduction, il ne s'agira simplement d'une seule unité de traduction, il ne fera qu'une (Attention: aléatoire, les compilateurs de courant ne se plaignent pas si vous fournissez différentes définitions du modèle dans différentes unités de traduction! ) et laisser cela dans le binaire final.

Maintenant, comme avec toutes les autres fonctions inline , le compilateur peut décider qu'il est une bonne idée d'éviter réellement l'appel de la fonction et de confier la fonction au lieu d'appel, ou peut déterminer que Ce n'est pas une bonne idée (grande fonction, certains compilateurs ne font pas de fonctions en ligne avec des boucles imbriquées ... Quelle que soit la raison), puis il n'effectuera pas l'affranchissement actuel du code.


1 commentaires

Et le compilateur peut décider de "en ligne" des fonctions qui ne sont pas déclarées en ligne . J'ai remarqué cela pour des fonctions sans liaison externe, lorsque vous utilisez gcc .



-1
votes

Les modèles sont des macros très très avancées (#define)

Les paramètres sont remplacés lors de la compilation avec les valeurs transmises. Vraiment génial concept et également mis en œuvre très bien.


1 commentaires

Les macros ne doivent pas être mélangés dans le pot avec des modèles et vous confondez déjà leurs concepts: les macros sont élargis dans la première étape de traduction, c'est-à-dire qu'ils peuvent produire des jetons qui doivent être transmis à l'analyseur C ++. Ce n'est pas possible avec des modèles.



0
votes

Les modèles sont une langue complète à eux-mêmes. Ils sont terminés, mais le «programme» fonctionne à l'heure de la compilation. Ce sont des usines de code qui remplacent le type d'objet au moment de la compilation et assemblent des classes, des fonctions, etc. lors de la compilation. Vous pouvez donc y penser comme un type de sécurité, un langage de prétraitement massif compatible C ++. La sortie résultante de l'exécution est un code C ++ pur qui peut ensuite être traité par le compilateur de la même manière que tout le reste.

Les compilateurs ignorent généralement en ligne alors que très peu de programmeurs peuvent vraiment savoir quand c'est le meilleur et ceux qui n'ont pas quitté l'assemblage.


0 commentaires