Bonsoir,

J'aurais aimé savoir, lorsqu'on utilise std::string::erase dans le cas précis où index = 0 (c'est-à-dire dans le cas où l'on souhaite supprimer les count premiers caractères de la std::string), est-ce

1. qu'on recopie toute la std::string (moins les count premiers caractères) dans un nouveau tableau,

ou bien,

2. est-ce que cela a été optimisé un peu et on met à 0 les count premiers caractères, puis on affecte l'adresse du nouveau premier caractère à l'adresse du tableau ?

Merci à vous. (Vous l'aurez compris, j'aimerais régulièrement supprimer le début de ma std::string sans devoir la recopier quasiment en entier à chaque fois ^^)

Je ne crois pas que le standard l'interdise, mais je n'ai vu aucune implémentation le faire. Tu devrais peut-être utiliser autre chose comme std::deque.

Hello Jo, merci de ta réponse.

Mais comment est-ce que std::deque s'y prend exactement pour effacer des éléments ? Cppreference dit que la complexité de deque::erase est linéaire en le nombre d'éléments non-effacés, ce qui semble être encore pire que std::vector.

Je crois qu'il me faudrait quelque chose comme std::queue, mais qui puisse effacer plusieurs éléments d'un coup plutôt qu'un par un.

Law. a écrit:

Cppreference dit que la complexité de deque::erase est linéaire en le nombre d'éléments non-effacés, ce qui semble être encore pire que std::vector.

Insertion or removal of elements at the end or beginning - constant O(1)
Insertion or removal of elements - linear O(n) 

la complexité est linéaire sur les éléments qui ne sont ni au début ni à la fin. Dans ton cas ils sont au début, donc la complexité est constante

Law. a écrit:

Mais comment est-ce que std::deque s'y prend exactement pour effacer des éléments ?

Les questions d'implémentation du standard dépendent du compilateur

----

Sinon tu peux gérer ton cas en utilisant 2 strings au lieu d'une. une string de data qui va être la partie qui bouge pas trop et une string prefix qui va changer souvent de contenu. et après tu exploites le résultat avec l'opérateur + de contaténation.

Et je sais pas quelle importance ce comportement a dans ton programme mais faire une classe qui le gère serait sûrement utile

D'accord, merci pour votre aide.

Question rapide, si je veux faire une custom string d'au plus 42 octets,

char* tab = new char[42];

l'octet qui suit immédiatement le 42ème n'est pas nécessairement mis à \0 sauf erreur, donc si je veux que ma custom string soit toujours terminée par \0, je suis en fait obligé de faire

char* tab = new char[43];

et de laisser le 43e octet à \0 de manière permanente, non ?

-
Edité par Law. 12 août 2019 à 14:01:34

Law. a écrit:

D'accord, merci pour votre aide.

Question rapide, si je veux faire une custom string d'au plus 42 octets,

char* tab = new char[42];

l'octet qui suit immédiatement le 42ème n'est pas nécessairement mis à \0 sauf erreur, donc si je veux que ma custom string soit toujours terminée par \0, je suis en fait obligé de faire

char* tab = new char[43];

et de laisser le 43e octet à \0 de manière permanente, non ?

Oublie cette manière de travailler!!!!   Tu développes en C++, et non en C, que diable!  Le code que tu présente ici, c'est du code C!  Facilite toi la vie et oublie purement et simplement cette odieuse pratique (du moins, quand tu code en C++), tu ne t'en sentiras que mieux et tes nuits seront bien meilleures

Moi non plus je n'aime pas mais on parlait de créer sa propre classe string, donc à partir de là, je dois bien allouer de la mémoire à un moment donné

Les probabilités sont qu'une recopie écrante est effectuée. C'est simple, et relativement efficace. En plus, ça va profiter des probables optimisation pour chaine courtes (SSO), qu'une implémentation type (naive?) avec buffer va systématiquement flinguer -- mais peut-être que tes chaines sont longues?

La _rope_ de la STL historique est possiblement plus proche de ce que tu cherches.

Mais... as-tu vu les std::string_view? C'est typiquement ce que tu cherches côté erase, mais cela implique que la mémoire est gérée ailleurs.