std::allocator pour char et wchar_t

Bonjour à tous,

je lisais récemment l'article de Andreas et Masur sur les allocateurs et je suis allé voir l'implémentation de l'allocateur par défaut de la STL (gcc-g++-4.6.3.tar.gz pour être exact).

Dans le fichier d'en-tête allocator.h, on y trouve bien tout ce qui est expliqué dans l'article (typedef, spécialisation pour le type void, ...). Jusque ici, tout va bien... Puis apparaissent les quelques lignes suivantes:

Code:

---

1 2 3 4 5 6

// Inhibit implicit instantiations for required instantiations, // which are defined via explicit instantiations elsewhere. #if _GLIBCXX_EXTERN_TEMPLATE extern template class allocator<char>; extern template class allocator<wchar_t>; #endif

---

Les instanciations spécialisées pour les types char et wchar_t apparaissent dans le fichier allocator-inst.cc,

Code:

---

1 2 3 4 5

namespace std { template class allocator<char>; template class allocator<wchar_t>; } // namespace std

---

La seule conséquence que je vois à ces spécialisations particulières est d'empêcher l'utilisateur de spécialiser lui-même les allocateurs pour char et pour wchar_t.

1. Est-ce le cas ou bien n'ai-je rien compris?
2. Y a-t-il d'autres conséquences/avantages à faire cela?
3. Pourquoi ne faire cela que pour les type char et wchar_t et pas pour d'autres types de base (int, float, ...)?

Mes questions sont peut-être naïves (désolé dans ce cas) mais j'aimerais bien comprendre ce qui motive ce choix pour les développeurs de la STL. Si certains peuvent éclairer ma lanterne, merci d'avance!

Instancier explicitement un template a pour effet d'instancier toutes ses fonctions membres, au lieu de ne les instancier qu'à la demande.

J'imagine qu'ici le but est que ces fonctions soient définies une fois, dans une bibliothèque. Et non pas à chaque usage.

Citation:

---

Envoyé par JolyLoic

Instancier explicitement un template a pour effet d'instancier toutes ses fonctions membres, au lieu de ne les instancier qu'à la demande.

---

Tu pourrais détailler, STP ?

Aux erreurs de syntaxe près (je n'utilise pas souvent ça) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

template<class T> class MaClasse { void g(T t) {t.f();} };   int main() { MaClass<int> a; // Pas d'erreur, la fonction g n'a pas encore été instanciée a.g(3); // Erreur, on tente d'instancier g, qui demande que T possède // une fonction membre nommée f }   template class MaClasse<double>; // Erreur, car là on instancie l'ensemble de // la classe MaClasse avec le type double, y compris la fonction g // qui pose le même problème que tout à l'heure

---

Merci JolyLoic pour ces réponses et cet exemple. Je crois comprendre un peu mieux maintenant: il ne s'agit pas particulièrement d'empêcher la spécialisation pour char et wchar_t mais plutôt d'assurer à la bibliothèque qu'elle dispose, au moins, d'un allocateur fonctionnel pour ces deux types. Cela répond à mes deux premières interrogations.

Pour la troisième, pourquoi se limiter uniquement à ces deux types? Peut être pour assurer le bon fonctionnement de std::string? Une autre idée me vient en tête, le type char étant le plus petit, assurer la capacité à allouer des char peut impliquer l'assurance de pouvoir allouer n'importe quoi de plus gros, via le rebind de l'allocateur... Est-ce une raison?

Salut,

Pour répondre à ta troisième question.

Je vois différentes raisons au fait que l'instanciation explicite soit faite pour les char et wchar:

D'abord, ce sont ces types primitifs qui sont utilisés comme type de base pour les chaines de caractères, pas les int, ni les float, ni quoi que ce soit d'autre: ce sont les char et éventuellement les char16_t /char32_t

Ensuite, une bonne majorité des conversions (et surtout celles qui ont recours à stringstream) se feront vers/ au départ des chaines de caractères.

En outre, la norme précise que la taille de n'importe quel type de donnée est calculée sur la base du caractère. En fournissant un allocateur spécifique pour le caractère, on a donc de toutes manière la certitude de pouvoir disposer d'un allocateur susceptible de travailler avec n'importe quel type.

Enfin, il faut savoir que le recours à l'instanciation explicite a tendance à augmenter la quantité de code binaire généré de manière assez significative.

Il peut "simplement" avoir semblé inutile aux développeurs de ta version de la STL de forcer la génération de code binaire pour l'allocateur des autres types primitifs alors que celui explicitement instancié pour le char (et le wchar_t) est "amplement suffisant" pour fonctionner avec tous les autres types ;)

Merci pour vos réponses, cela clarifie pas mal de choses sur ces instanciations :ccool: