Est-ce que l'utilisation de std :: array <T, N> conduire à gonfler le code?

Question

J'ai vu dans quelques endroits de la recommandation de l'utilisation de std::array C-le style des tableaux en C++, clamant que c'est un mieux, alternative plus sûre avec pas de frais généraux. Voir:

Le conteneur standard array [...] n'a pas d'espace frais généraux au-delà de ce il doit tenir ses éléments, [...]. En d'autres termes, il est très bien comme un construit-dans la gamme sans problèmes. (C++11 FAQ)

Cependant, comme je le comprends, d'être un modèle de conteneur, il y aura un frais généraux autant que la taille du programme en va, car il va générer du code pour chaque N un tableau est instanciée avec.

Supposons que mon programme utilise std::array en divers endroits avec différents nombres entiers de N, cela conduira à ballonnement code? Est-il négligeable?

Dois-je m'inquiéter au sujet de cette non-type de paramètres du modèle en général?

Answer 1

Je ne serais pas s'inquiéter à ce sujet. Si vous regardez à l'interface de l' std::array<T, N>, il est très petit et la plupart des fonctions de membre (pour l'essentiel en fournissant des wrappers pour manipulation du pointeur) sont des one-liners qui sera complètement optimisé loin / inline par n'importe quel compilateur décent sur le mode de Libération niveaux d'optimisation.

En outre, vous ne payez pas pour ce que vous n'utilisez pas depuis inutilisée non-virtuel fonctions de membre (std::array<T, N> n'ont pas d' virtual fonctions membres) de la classe de modèles sont garantis de ne pas être instanciée. Petit Standard citation:

14.7.1 instanciation Implicite [temp.inst]

11 Une mise en œuvre ne doit pas implicitement instancier une fonction modèle, une variable de template, un membre, un modèle non-membre virtuel fonction, un membre de la classe, ou une donnée membre statique d'une classe template qui ne nécessite pas d'instanciation. [...]

Il y a aussi quelques surcharge d'opérateurs relationnels == et < qui sont sémantiquement équivalents std::equal et std::lexicographical_compare. Dans la pratique, ces opérateurs doivent également être mises en œuvre en termes de ces algorithmes (plaignez-vous à votre fournisseur si ils ne le font pas).

Le seul très petit souci, c'est un peu plus au moment de la compilation des frais généraux, mais il devrait être égale à zéro, le code de la taille et de l'exécution de frais généraux.

Liés mais n'est pas identique: le Rapport Technique sur les Performances de C++ a fait beaucoup d'attention des repères sur de minces classe wrappers autour builtin types (int, double) et proches de zéro frais généraux pour 2006 compilateur de la technologie. Vous pourriez répéter leurs test pour vérifier cela pour std::array<T,N> vs T[N]