Zalety semantyki kopiowania przy zapisie

Zastanawiam się, jakie są możliwe zalety kopiowania przy zapisie? Oczywiście nie oczekuję osobistych opinii, ale praktyczne scenariusze z rzeczywistego świata, w których może to być technicznie i praktycznie korzystne w namacalny sposób. A przez namacalny mam na myśli coś więcej niż oszczędzanie pisania &postaci.

Aby wyjaśnić, to pytanie jest w kontekście typów danych, w których konstrukcja przypisania lub kopii tworzy niejawną płytką kopię, ale modyfikacje w niej tworzą niejawną głęboką kopię i stosuje do niej zmiany zamiast oryginalnego obiektu.

Powodem, dla którego pytam, jest to, że nie znajduję żadnych zalet posiadania COW jako domyślnego domyślnego zachowania. Używam Qt, który ma COW zaimplementowany dla wielu typów danych, praktycznie wszystkich, które mają jakieś dynamiczne przydzielanie pamięci. Ale jak to naprawdę wpływa na użytkownika?

Przykład:

QString s("some text");
QString s1 = s; // now both s and s1 internally use the same resource

qDebug() << s1; // const operation, nothing changes
s1[o] = z; // s1 "detaches" from s, allocates new storage and modifies first character
           // s is still "some text"

Co wygrywamy, używając COW w tym przykładzie?

Jeśli wszystko, co zamierzamy zrobić, to użyć operacji const, s1jest redundantne, może równie dobrze użyć s.

Jeśli zamierzamy zmienić wartość, wówczas COW opóźnia kopię zasobu tylko do pierwszej operacji non-const, przy (choć minimalnym) koszcie zwiększenia liczby odwołań dla niejawnego udostępniania i odłączania od pamięci wspólnej. Wygląda na to, że cały koszt związany z COW jest bezcelowy.

Nie różni się zbytnio w kontekście przekazywania parametrów - jeśli nie zamierzasz modyfikować wartości, podaj jako const referen, jeśli chcesz zmodyfikować, albo wykonaj niejawną głęboką kopię, jeśli nie chcesz modyfikować oryginalny obiekt lub przekaż referencję, jeśli chcesz go zmodyfikować. Ponownie COW wydaje się niepotrzebnym narzutem, który niczego nie osiąga, i dodaje jedynie ograniczenie, że nie możesz modyfikować oryginalnej wartości, nawet jeśli chcesz, ponieważ każda zmiana odłączy się od oryginalnego obiektu.

Tak więc w zależności od tego, czy wiesz o COW, czy jesteś tego nieświadomy, może to skutkować kodem z niejasnym zamiarem i niepotrzebnym narzutem, lub całkowicie mylącym zachowaniem, które nie spełnia oczekiwań i powoduje, że drapiesz się po głowie.

Wydaje mi się, że istnieją bardziej wydajne i czytelniejsze rozwiązania, niezależnie od tego, czy chcesz uniknąć niepotrzebnej głębokiej kopii, czy zamierzasz ją wykonać. Więc gdzie jest praktyczna korzyść z COW? Zakładam, że musi to przynieść pewne korzyści, ponieważ jest wykorzystywany w tak popularnym i potężnym frameworku.

Co więcej, z tego, co przeczytałem, COW jest teraz wyraźnie zabronione w standardowej bibliotece C ++. Nie wiem, czy wady, które w nim widzę, mają coś z tym wspólnego, ale tak czy inaczej, musi być ku temu powód.

Kopiuj przy zapisie jest używany w sytuacjach, w których bardzo często tworzona jest kopia obiektu, a nie modyfikowana. W takich sytuacjach opłaca się.

Jak wspomniałeś, możesz przekazać stały obiekt, a w wielu przypadkach jest to wystarczające. Jednak const gwarantuje tylko, że osoba dzwoniąca nie może go zmutować (chyba że const_castoczywiście). Nie obsługuje przypadków wielowątkowości i nie obsługuje przypadków, w których istnieją wywołania zwrotne (które mogą mutować oryginalny obiekt). Przekazywanie obiektu COW według wartości stawia wyzwania związane z zarządzaniem tymi szczegółami przed deweloperem interfejsu API, a nie użytkownikiem interfejsu API.

Nowe zasady dla C + 11 zabraniają std::stringw szczególności COW . Iteratory ciągu muszą zostać unieważnione, jeśli bufor kopii zapasowej zostanie odłączony. Jeśli iterator był implementowany jako char*(W przeciwieństwie do string*indeksu i), iteratory nie są już ważne. Społeczność C ++ musiała zdecydować, jak często iteratory mogą być unieważniane, i zdecydowano, że operator[]nie powinien to być jeden z tych przypadków. operator[]na std::stringzwrotach a char&, które mogą być modyfikowane. Dlatego operator[]musiałby odłączyć ciąg, unieważniając iteratory. Uznano to za słabą wymianę handlową i w przeciwieństwie do funkcji takich jak end()i cend(), nie ma możliwości, aby poprosić o wersję const operator[]krótkiego od const rzucającego ciąg. ( powiązane ).

COW wciąż żyje i znajduje się poza STL. W szczególności uważam, że jest to bardzo przydatne w przypadkach, w których użytkownik moich interfejsów API nie ma uzasadnienia, aby oczekiwać, że za czymś, co wydaje się być bardzo lekkim przedmiotem, jest jakiś ciężki obiekt. Mogę chcieć użyć COW w tle, aby upewnić się, że nigdy nie będą musieli zajmować się takimi szczegółami wdrożenia.

Wydaje się, że w przypadku ciągów znaków i pesymizacji bardziej powszechne przypadki użycia niż nie, ponieważ częstym przypadkiem ciągów są często małe ciągi, a tam narzut COW zwykle przewyższałby koszt zwykłego kopiowania małego ciągu. Mała optymalizacja bufora ma dla mnie znacznie większy sens, aby uniknąć przydziału sterty w takich przypadkach zamiast kopii ciągów.

Jeśli jednak masz cięższy obiekt, taki jak android, a chciałeś go skopiować i po prostu wymienić jego cybernetyczne ramię, COW wydaje się całkiem rozsądnym sposobem na zachowanie zmiennej składni przy jednoczesnym unikaniu konieczności głębokiego kopiowania całego Androida tylko w celu nadaj kopii wyjątkowe ramię. Uczynienie go po prostu niezmiennym jako trwała struktura danych w tym momencie może być lepsza, ale „częściowe COW” zastosowane na poszczególnych częściach Androida wydaje się uzasadnione w tych przypadkach.

W takim przypadku dwie kopie Androida dzieliłyby / wystąpiły ten sam tors, nogi, stopy, głowę, szyję, ramiona, miednicę itp. Jedyne dane, które byłyby między nimi różne i nie byłyby udostępnione, to ramię, które zostało wykonane unikalny dla drugiego Androida po nadpisaniu ramienia.