C++ STL allocateur vs nouvel opérateur

Selon C++ Primer 4e édition, page 755, il y a une note disant:

Moderne les programmes C++ normalement devrait utiliser l'allocateur de classe
pour allouer de la mémoire. Il est plus sûr et plus souple.

Je n'arrive pas à comprendre cette déclaration.
Jusqu'à présent, tous les matériaux que j'ai lu d'enseigner à l'aide new d'allouer de la mémoire en C++.
Un exemple de la façon dont la classe vector utiliser allocateur est indiqué dans le livre.
Cependant, je ne peux pas penser à d'autres scénarios.

N'importe qui peut aider à clarifier cette déclaration? et de me donner d'autres exemples?
Quand dois-je utiliser l'allocation et quand utiliser new? Merci!

InformationsquelleAutor Ivan Z. Siu | 2011-04-11
  1. 39

    Pour la programmation en général, oui, vous devriez utiliser new et delete.

    Toutefois, si vous écrivez une bibliothèque, vous ne devriez pas!
    Je n'ai pas votre livre, mais j'imagine que c'est en train de discuter allocateurs dans le contexte de la rédaction du code de la bibliothèque.

    Les utilisateurs d'une bibliothèque peuvent veulent contrôler exactement ce qui est attribué à partir d'où. Si l'ensemble de la bibliothèque des allocations sont allés à travers new et delete, l'utilisateur n'a aucun moyen d'avoir cette fine niveau de contrôle.

    Tous les conteneurs STL prendre une option allocateur de l'argument de modèle. Le conteneur va ensuite utiliser que de l'allocateur de mémoire interne de besoins. Par défaut, si vous omettez l'allocateur, il utilisera std::allocator qui utilise new et delete (plus précisément, ::operator new(size_t) et ::operator delete(void*)).

    De cette façon, l'utilisateur de ce conteneur de contrôle où la mémoire est attribué à partir s'ils le désirent.

    Exemple de mise en œuvre d'un allocateur personnalisé pour une utilisation avec la STL, et l'explication: L'amélioration des Performances avec la Coutume de la Piscine Allocateurs de la STL

    Note de côté: La STL approche allocateurs est non optimale de plusieurs façons. Je recommande la lecture de Vers une Meilleure Allocation de Modèle pour une discussion de certaines de ces questions.

    • +1 pour le "STL approche allocateurs est pas optimale" de plus, le lien vers "Vers une Meilleure Allocation de Modèle" 🙂
    • Le lien que vous avez fourni est très utile!
    InformationsquelleAutor jwd
  2. 1

    Les deux ne sont pas contradictoires. Allocateurs sont un PolicyPattern ou StrategyPattern utilisé par le TSL bibliothèques contenant des adaptateurs pour allouer des blocs de mémoire pour une utilisation avec des objets.

    Ces allocateurs souvent d'optimiser l'allocation de la mémoire en permettant
    * gammes d'éléments pour être affecté à la fois, et ensuite initialisé à l'aide d'un placement de nouveaux
    * éléments devant être sélectionnés à partir du secondaire, spécialisé tas en fonction de la taille de bloc

    D'une manière ou d'une autre, le résultat final sera (presque toujours) que les objets sont alloués par de placement ou par défaut)

    Un autre exemple frappant serait par exemple stimuler la bibliothèque implémente smartpointers. Parce que smartpointers sont de très petite taille (à peu de frais généraux), l'allocation de frais généraux peut devenir un fardeau. Il serait judicieux pour la mise en œuvre à définir une institution spécialisée de l'allocateur de faire les dotations, de sorte que l'on peut avoir efficace std::set<> de smartpointers, std::map<..., smartpointer> etc.

    (Maintenant je suis presque sûr que booster optimise en fait de stockage pour la plupart des smartpointers en évitant toute virtuals, donc la vft, faire de la classe un POD de la structure, avec seulement le pointeur brut que le stockage; certains de l'exemple ne s'applique pas. Mais là encore, extrapoler à d'autres types de smartpointer (compteurs refcount smartpointers, des pointeurs vers des fonctions de membre, des pointeurs vers des fonctions de membre d'instance de référence, etc. etc.))

    InformationsquelleAutor sehe