Légalité de l'implémentation COW std::string en C++11

Question

J'avais cru comprendre que la copie sur l'écriture n'était pas un moyen viable d'implémenter un système conforme. std::string dans C++11, mais lorsque la question a été abordée récemment, je me suis trouvé dans l'incapacité de soutenir directement cette affirmation.

Ai-je raison de dire que C++11 n'admet pas les implémentations basées sur COW de std::string ?

Si oui, cette restriction est-elle explicitement indiquée quelque part dans la nouvelle norme (où) ?

Ou bien cette restriction est-elle implicite, en ce sens qu'il s'agit de l'effet combiné des nouvelles exigences en matière de std::string qui empêche une implémentation basée sur COW de std::string . Dans ce cas, je serais intéressé par une dérivation de type chapitre et verset de la phrase "C++11 interdit effectivement la méthode COW". std::string mises en œuvre".

Answer 1

Ce n'est pas autorisé, car selon la norme 21.4.1 p6, l'invalidation des itérateurs/références n'est autorisée que dans les cas suivants

- comme argument à toute fonction de la bibliothèque standard prenant une référence à basic_string non-const comme argument.

- Appel de fonctions membres non constantes sauf operator[], at, front, back, begin, rbegin, end, et rend.

Pour une chaîne COW, l'appel à une chaîne non-const. operator[] nécessiterait de faire une copie (et d'invalider les références), ce qui est interdit par le paragraphe ci-dessus. Par conséquent, il n'est plus légal d'avoir une chaîne COW en C++11.

Answer 2

Les réponses de Dave S et gbjbaanb sont correct . (Et celle de Luc Danton est correcte aussi, bien qu'il s'agisse plutôt d'un effet secondaire de l'interdiction des chaînes COW que de la règle originale qui l'interdit).

Mais pour dissiper toute confusion, je vais ajouter quelques explications supplémentaires. Divers commentaires renvoient à un de mes commentaires sur le bugzilla de GCC qui donne l'exemple suivant :

std::string s("str");
const char* p = s.data();
{
    std::string s2(s);
    (void) s[0];
}
std::cout << *p << '\n';  // p is dangling

Le but de cet exemple est de démontrer pourquoi la chaîne de référence comptée (COW) de GCC n'est pas valide en C++11. La norme C++11 exige que ce code fonctionne correctement. Rien dans ce code ne permet au p pour être invalidée dans C++11.

Utilisation de l'ancien comptage de référence de GCC std::string ce code a un comportement non défini, parce que p es invalidée, devenant ainsi un pointeur suspendu. (Ce qui se passe, c'est que lorsque s2 est construit, il partage les données avec s mais l'obtention d'une référence non conforme via s[0] exige que les données ne soient pas partagées, donc s fait une "copie sur l'écriture" parce que la référence s[0] pourrait potentiellement être utilisé pour écrire dans s alors s2 sort de son champ d'application, détruisant le tableau pointé par p ).

La norme C++03 permet explicitement ce comportement dans 21.3 [lib.basic.string] p5 où il est dit que suite à un appel à data() le premier appel à operator[]() peut invalider les pointeurs, les références et les itérateurs. La chaîne COW de GCC était donc une implémentation C++03 valide.

La norme C++11 ne permet plus ce comportement, car aucun appel à operator[]() peut invalider des pointeurs, des références ou des itérateurs, qu'ils suivent ou non un appel à la fonction data() .

Ainsi, l'exemple ci-dessus debe fonctionnent en C++11, mais n'est pas ne fonctionne pas avec le type de chaîne COW de libstdc++, ce type de chaîne COW n'est donc pas autorisé en C++11.

Answer 3

C'est le cas, le CoW est un mécanisme acceptable pour faire des cordes plus rapides... mais...

il rend le code multithreading plus lent (tout ce verrouillage pour vérifier si vous êtes le seul à écrire nuit aux performances lorsque vous utilisez beaucoup de chaînes de caractères). C'est la raison principale pour laquelle CoW a été tué il y a des années.

Les autres raisons sont que le [] vous renverra les données de la chaîne, sans aucune protection pour vous permettre d'écraser une chaîne que quelqu'un d'autre s'attend à voir inchangée. Il en va de même pour c_str() y data() .

Un rapide coup d'œil sur Google indique que le multithreading est fondamentalement le raison pour laquelle elle a été effectivement rejetée (non explicitement).

La proposition dit :

Proposition

Nous proposons de rendre toutes les opérations d'accès aux itérateurs et aux éléments en toute sécurité exécutables simultanément.

Nous augmentons la stabilité des opérations même dans un code séquentiel.

Ce changement interdit effectivement les implémentations de copie sur écriture.

suivi par

La plus grande perte potentielle de performance due à l'abandon des implémentations de copie sur écriture est la consommation accrue de mémoire. des implémentations de copie sur écriture est la consommation accrue de mémoire pour les applications comportant de très grandes chaînes de caractères en lecture seule. Cependant, nous Cependant, nous pensons que pour ces applications, les cordes sont une meilleure solution technique. solution technique, et nous recommandons qu'une proposition de corde soit considérée pour être incluse dans la Bibliothèque TR2.

Cordes font partie de STLPort et de SGIs STL.

Answer 4

De 21.4.2 constructeurs et opérateurs d'assignation de basic_string [string.cons].

basic_string(const basic_string<charT,traits,Allocator>& str);

[...]

2 Effets : Construit un objet de la classe basic_string comme indiqué dans le tableau 64. [...]

Le tableau 64 documente utilement qu'après la construction d'un objet via ce constructeur (copie), this->data() a comme valeur :

pointe le premier élément d'une copie allouée du tableau dont le premier élément est pointé par str.data()

Il existe des exigences similaires pour d'autres constructeurs similaires.

Answer 5

Puisqu'il est maintenant garanti que les chaînes de caractères sont stockées de manière contiguë et que vous êtes maintenant autorisé à prendre un pointeur vers le stockage interne d'une chaîne de caractères (c'est-à-dire que &str[0] fonctionne comme pour un tableau), il n'est pas possible de faire une implémentation COW utile. Il faudrait faire une copie pour beaucoup trop de choses. Même en utilisant simplement operator[] o begin() sur une chaîne non constante nécessiterait une copie.