Comment dois-je allouer un std::string sur la pile à l'aide de la glibc dans la chaîne de mise en œuvre?

int main(void)
{
   std::string foo("foo");
}

Ma compréhension est que le code ci-dessus utilise la valeur par défaut de l'allocateur pour appeler de nouveaux. Ainsi, même si les std::string toto est alloué sur la pile de la mémoire tampon interne à l'intérieur de foo est alloué sur le tas.

Comment puis-je créer une chaîne qui est entièrement allouée sur la pile?

  • Permettez-moi de modifier que "comment puis-je créer un std::basic_string qui est entièrement allouée sur la pile?"
  • Juste à relier à une question similaire: stackoverflow.com/questions/354442/...
InformationsquelleAutor poindexter | 2009-04-23
  1. 21

    Je voulais le faire moi-même récemment et a trouvé le code suivant éclairante:

    Chronium de stack_container.h

    Il définit une nouvelle std::allocator qui peut fournir la pile en fonction de répartition de la dotation initiale de stockage pour les conteneurs STL. J'ai fini par trouver un autre moyen de résoudre mon problème, donc je n'ai pas utiliser le code moi-même, mais ce sera peut-être utile pour vous. Assurez vous de lire les commentaires dans le code concernant l'utilisation et les mises en garde.

    À ceux qui ont mis en doute l'utilité et de la raison de le faire, pensez à:

    • Souvent vous savoir a priori que votre chaîne a un motif raisonnable de taille maximale. Par exemple, si la chaîne va stocker un nombre décimal format entier de 32 bits,vous savez que vous n'avez pas besoin de plus de 11 caractères pour le faire. Il n'est pas nécessaire pour une chaîne qui peut développer dynamiquement à la taille illimitée dans ce cas.
    • L'allocation à partir de la pile est plus rapide dans de nombreux cas, de l'allocation dans le tas.
    • Si la chaîne est créé et détruit fréquemment (supposons que c'est une variable locale dans couramment utilisée pour la fonction d'utilité), l'allocation de la pile au lieu de le tas éviter la fragmentation induisant des taux de désabonnement dans le tas allocateur. Pour les applications qui utilisent beaucoup de mémoire, cela pourrait être un changeur de jeu.

    Certaines personnes ont fait remarquer qu'une chaîne qui utilise la pile, l'allocation ne sera pas un std::string comme si en quelque sorte ce qui diminue son utilité. Vrai, vous ne pouvez pas utiliser les deux de façon interchangeable, donc vous ne serez pas en mesure de passer votre stackstring à des fonctions attend à une std::string. Mais (si vous le faites à droite), vous serez en mesure d'utiliser toutes les mêmes fonctions de membre sur votre stackstring que vous utilisez maintenant sur std::string, comme find_first_of(), append(), etc. begin() et end() fonctionnent encore correctement, de sorte que vous serez en mesure d'utiliser la plupart des algorithmes de la STL. Bien sûr, il ne sera pas std::string dans le sens le plus strict, mais il sera toujours un "string" dans le sens pratique, et il sera toujours très utile.

    • Merci pour le pointeur à certains intéressant de code.
    • Vous pouvez utiliser les algorithmes de la STL nue un tableau de char sur la pile, mais quelqu'un a suggéré que et la a voté vers le bas. Interlocuteur auront à décider quelles sont les caractéristiques de std::string il a besoin...
    • Cela ne fonctionne pas pour glibc std::basic_string, il appelle l'Allocateur de constructeur par défaut, qui StackAllocator ne prend pas en charge.
    • Cette URL ne fonctionne plus. Voici la mise à jour d'un: http://src.chromium.org/viewvc/chrome/trunk/src/base/containers/stack_container.h?view=markup
    • merci pour le heads up, j'ai mis à jour la réponse avec le nouveau lien.
    InformationsquelleAutor Eric Melski
  2. 11

    Le problème est que std::basic_string a un paramètre de modèle pour l'allocateur. Mais std::string n'est pas un modèle et n'a pas de paramètres.

    Ainsi, vous pouvez en principe utiliser une instanciation de std::basic_string avec un allocateur qui utilise de la mémoire sur la pile, mais il ne serait pas un std::string. En particulier, vous n'en aurez pas polymorphisme d'exécution, et vous ne pouvais pas laisser passer les objets qui en résultent dans les fonctions attend à une std::string.

    • Je ne suis pas sûr de comment cela pourrait fonctionner? Exactement comment vous proposez-vous d'avoir l'allocateur de modifier la trame de pile de son visiteur? Simplement en faisant une alloca() dans l'allocateur ne fonctionnera pas parce que la mémoire serait automatiquement libérée lorsque l'allocateur retourne le pointeur, ou lorsque le std::string constructeur de retours si l'allocation a été insérée.
    • Me battre pour elle 🙂
    • Vous avez tout à fait raison, l'allocation ne peut fonctionner que parce qu'il n'a pas dit où sur la pile de données qu'il voulait la chaîne de l'être. L'allocateur auraient besoin d'un accès à un bloc de pile via les données de l'instance. Un peu comme DJB sûre de la chaîne de bibliothèques (C, pas du C++), dont l'utilisation limitée d'un bloc d'espace de pile parce que c'est un moyen simple et peu onéreux pour limiter l'utilisation de la mémoire par thread
    • "où sur la pile de données qu'il voulait la chaîne de l'être". Je veux dire, "où, sur la pile qu'il voulait la chaîne de données". Et j'ai peut-être mal rappelé DJB du code, c'était il y a longtemps que je l'ai vu.
    InformationsquelleAutor Steve Jessop
  3. 4

    Vous ne pouvez pas. Sauf que...

    std::string est une instanciation de

    std::basic_string<class CharType, 
                  class Traits=char_traits<CharType>, 
                  class Allocator=allocator<CharType> >

    Vous pourrait éventuellement définir un Allocateur de classe qui l'utilise alloca pour la gestion de la mémoire. Cela ne fonctionne que si l'Allocateur de lui-même, et le basic_string méthodes que l'invoquer directement ou indirectement, sont tous inline. Un basic_string objet créé avec cette allocation ne serait pas être un std::string, mais il allait se comporter (en grande partie) comme il. Cependant, ce serait une bonne quantité de travail pour des gains limités. Plus précisément, l'utilisation de cette classe pour les valeurs de retour d'une fonction serait un obstacle à l'avancement.

    Je n'ai aucune idée de pourquoi vous ou quelqu'un d'autre aurait envie de le faire.

    • +1, modulo le commentaire de ma réponse, que alloca n'a pas vraiment le faire parce que std::basic_string appels vers le bas dans l'allocateur, de sorte qu'il est "trop tard" alors utiliser alloca. Ne me souviens pas comment alloca interagit avec l'in-lining, mais - peut-être avec du brutal montants il se pourrait donc arriver à travailler pour un particulier STL mise en œuvre et les paramètres du compilateur?
    • Le compilateur aurait besoin d'aller moyen de sortir de sa façon de donner des méthodes inline leur propre cadre de pile. Otoh, que, en plaçant des paris sur qui est l'autre obstacle à l'avancement.
    • alloca n'est pas POSIX, donc je ne vais même pas l'envisager. Quant à savoir pourquoi quelqu'un voudrait pour ce faire, je vous Eric Melski de réponse.
    • Une utilisation de cette technique est de préserver la localité des données.Cela peut être utile lors de la conception d'un AST, il est tout à fait envisageable de décider de la taille maximale d'une chaîne de caractères identifiant dans un AST. Il y a probablement des dizaines d'autres cas d'utilisation. C++ est parfaitement adapté langue à utiliser pour la création de ressources limitées de modèles.
    • Cette réponse est fausse, alloca alloue à partir d'une des fonctions locales frame de pile. Une fois que cela est hors de portée, la mémoire allouée est automatiquement libéré.
    • Tel que discuté dans les commentaires ci-dessus, il est probable que le travail à condition qu'il n'y a pas non en ligne de méthodes entre l'appelant et l'allocateur. (J'ai édité la réponse à souligner cette restriction.) Mais même si elle a fait un travail, c'est toujours une mauvaise idée de les mettre en pratique. J'ai écrit cela comme une expérience de pensée, non pas comme un sérieux la suggestion de quelqu'un pour le mettre en œuvre. La marche à travers la façon dont cette à travail peut jeter une certaine lumière sur la façon dont basic_string et allocateurs de travail, et pourquoi vous vous ne pouvez pas faire beaucoup avec dynamique de la mémoire sur la pile.

    InformationsquelleAutor Dan Breslau
  4. 0

    Je soupçonne que de faire une telle chose serait difficile de le faire, je me demande pourquoi vous voulez le faire? Pour allouer quelque chose d'entièrement sur la pile, le compilateur doit savoir au moment de la compilation de ce que la taille exacte de la chose est dans votre exemple, il serait nécessaire de connaître non seulement la taille de la std::string de métadonnées, mais aussi de la taille de la chaîne de données elle-même. Ce n'est pas trop souple, vous auriez probablement besoin de différents types de chaînes en fonction de la taille de la chaîne de données que vous souhaitez inclure dans ti - pas qu'il serait impossible à faire, il aurait tendance à compliquer un peu les choses.

    • "vous auriez probablement besoin de différents types de chaînes en fonction de la taille de la chaîne de données que vous souhaitez inclure en elle". Bienvenue sur Symbian!
    InformationsquelleAutor 1800 INFORMATION
  5. -3
    • std::string toujours gérer la mémoire de stockage interne avec de new/delete.
    • Ne savez pas pourquoi votre question contient de glibc chaîne de mise en œuvre. La chaîne de mise en œuvre de la norme c++ de la bibliothèque n'a rien à voir avec glibc.
    • La seule façon de stocker une chaîne de caractères sur la pile est d'utiliser un C char tableau sur la pile (comme ce que Shhnap décrites). Mais ce n'est probablement pas ce que vous voulez de toute façon 🙂
    • Est-il vraiment quelque chose dans la norme en ce qui concerne le premier point.. autant que je sache, la mise en œuvre interne est libre de faire la petite taille de la chaîne d'optimisations et de ne pas impliquer tas.
    • Majkara est correcte, les petites chaînes de caractères(<16 caractères dans le MSVC mise en œuvre) sont généralement allouée sur la pile et n'impliquent pas des tas d'allocation de mémoire.
    • std::string définit l'interface pas la mise en œuvre. Je suis spécialement poser des questions sur la mise en œuvre de la glibc parce que c'est ce que je suis en train de travailler avec. Si j'ai été en utilisant le MSVC mise en œuvre, je ne serais pas en posant cette question. Heureusement, j'ai eu une réponse qui est de la mise en œuvre indépendante.
    • la glibc ne dispose PAS d'un std::string mise en œuvre. c'est dans libstdc++ gcc.
    • Tito Le fait que la mise en œuvre de certains compilateurs ne petite taille de la chaîne des optimisations ne signifie pas que vous pouvez écrire (portable), C++ où votre chaîne n'est pas le virus de l'hépatite alloué.
    InformationsquelleAutor lothar