Discussion :

[fabien007]

Bonjour à tous,

Jusqu'à présent, j'utilisais des c-string (un simple tableau de char) plutot que des c++ string pour des raisons de performance (je n'ai que récemment découvert les moultes réallocations(!!) des string c++).

Je trouve dommage d'avoir à préallouer à chaque fois ce tableau, car je me retrouve à hardcoder ces valeurs et il est courant d'allouer bien plus que nécessaire.
Je ne fais que insérer des chaines de caractères au début (rarement) et à la fin (toujours). J'ai aussi parfois besoin supprimer les n derniers caractères (ou de reculer et de les overwriter ce qui revient au même).


J'ai donc codé une solution intermédiaire à base de listes chaînées de c-string, en ayant un proxy qui alloue de nouveaux blocks si nécessaire. Le problème, c'est que je dois maintenir un contexte qui contient des infos telles que la position du curseur courant du block courant, l'adresse du block courant etc... Et ce maintient est couteux.

J'ai fait quelques recherches sur le WWW à la recherche de solutions miracles, et j'ai peut etre trouvé mon bonheur dans les ropes (http://www.sgi.com/tech/stl/Rope.html), dont l'implémentation GNU semble être exactement reprise de SGI.

Déjà, pensez-vous que je suis sur une bonne piste?

Si oui, je me demande si je pourrai raisonnablement créer des iovecs à partir des blocks internes des ropes pour éviter des copies inutiles..

Merci bcp

[Laurent Gomila]

Personnellement, je n'ai jamais eu de problème de performances dûes aux mitouilles internes des std::string. Et si vraiment cela posait problème, j'imagine qu'en gérant bien les allocations (à coup de reserve() et autres) tu devrais pouvoir résoudre le problème.

En ce qui concerne la classe rope, il me semblait avoir lu que c'était utile surtout pour les chaînes immenses. Maintenant, si c'est effectivement ce que tu manipules, alors oublie ce que je viens de dire.

[fabien007]

Merci Loulou24 pour ta réponse.
Je n'ai pas vraiment à gérer de chaines immenses (bien que ca peut facilement monter à plrs centaines de ko).
Je n'ai rien de particulier contre les string, sinon leur sous efficacité lors des réallocations et l'impossibilité apparente d'en extraire facilement des iovecs. En fait je commence à croire qu'utiliser des deque bidirectionnelles de tableau de char devrait le faire..

[Médinoc]

Dans ce cas, pourquoi n'utilises tu pas directement des vector ou deque de char ? (les deque sont implémentées avec des listes chaînées de tableaux...)