Преимущества семантики копирования при записи

Мне интересно, какие возможные достоинства есть у копирования при записи? Естественно, я не жду личных мнений, но реальных практических сценариев, где это может быть технически и практически выгодно ощутимым образом. И под осязаемым я имею в виду нечто большее, чем спасение вас от набора &символов.

Для пояснения этот вопрос относится к типам данных, где конструкция присваивания или копирования создает неявную поверхностную копию, но при ее модификации создается неявная глубокая копия и применяется к ней изменения вместо исходного объекта.

Причина, по которой я спрашиваю, заключается в том, что я не вижу каких-либо преимуществ использования COW в качестве неявного поведения по умолчанию. Я использую Qt, в котором COW реализован для многих типов данных, практически для всех, которые имеют некоторое динамическое распределение памяти. Но как это может принести пользу пользователю?

Пример:

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"

Что мы выиграем, используя COW в этом примере?

Если все, что мы собираемся сделать, это использовать константные операции, s1это избыточно, может также использоваться s.

Если мы намереваемся изменить значение, то COW только задерживает копирование ресурса до первой неконстантной операции, за счет (хотя и минимальной) стоимости увеличения числа ссылок для неявного совместного использования и отключения от общего хранилища. Похоже, что все накладные расходы, связанные с COW, бессмысленны.

Он не сильно отличается в контексте передачи параметров - если вы не собираетесь изменять значение, передайте как константную ссылку, если вы хотите изменить, вы либо создаете неявную глубокую копию, если не хотите изменять исходный объект, или передайте по ссылке, если вы хотите изменить его. Опять же, COW кажется ненужными накладными расходами, которые ничего не достигают, а лишь добавляет ограничение, что вы не можете изменять исходное значение, даже если хотите, так как любое изменение отсоединит от исходного объекта.

Таким образом, в зависимости от того, знаете ли вы о COW или не обращаете на это внимания, это может привести либо к коду с неясными намерениями и ненужными накладными расходами, либо к полностью запутывающему поведению, которое не соответствует ожиданиям и заставляет вас ломать голову.

Мне кажется, что есть более эффективные и более удобочитаемые решения, хотите ли вы избежать ненужной глубокой копии или намереваетесь ее сделать. Так где же практическая выгода от COW? Я предполагаю, что должна быть некоторая выгода, поскольку в ней используются такие популярные и мощные рамки.

Кроме того, из того, что я прочитал, COW теперь явно запрещено в стандартной библиотеке C ++. Не знаю, имеет ли отношение к этому мошенничество какое-то отношение, но в любом случае, для этого должна быть причина.

Копирование при записи используется в ситуациях, когда вы очень часто создаете копию объекта, а не изменяете ее. В таких ситуациях это окупается.

Как вы упомянули, вы можете передать объект const, и во многих случаях этого достаточно. Тем не менее, const только гарантирует, что вызывающая сторона не может изменить его (если они const_cast, конечно, не). Он не обрабатывает случаи многопоточности и не обрабатывает случаи, когда существуют обратные вызовы (которые могут изменить исходный объект). Передача объекта COW по значению ставит задачи управления этими деталями разработчику API, а не пользователю API.

Новые правила для C + 11 запрещают COW std::stringв частности. Итераторы в строке должны быть недействительными, если резервный буфер отключен. Если итератор был реализован как a char*(в отличие от a string*и индекса), эти итераторы больше не действительны. Сообщество C ++ должно было решить, как часто итераторы могут быть признаны недействительными, и было решено, что это operator[]не должно быть одним из таких случаев. operator[]на a std::stringвозвращает char&, который может быть изменен. Таким образом, operator[]потребуется отсоединить строку, лишив законной силы итераторы. Считалось, что это плохая сделка, и в отличие от таких функций, как end()и cend(), нет никакого способа запросить константную версию operator[]короткого замыкания на константное приведение строки. ( связано ).

COW все еще жив и далеко за пределами STL. В частности, я считаю, что это очень полезно в тех случаях, когда пользователю моих API нецелесообразно ожидать, что за каким-то очень легким объектом стоит какой-то тяжеловесный объект. Я могу пожелать использовать COW в фоновом режиме, чтобы они никогда не интересовались такими деталями реализации.

Для строк и тому подобного кажется, что это приведет к пессимизации более распространенных вариантов использования, чем нет, поскольку общий случай для строк часто представляет собой небольшие строки, и в этом случае издержки COW будут значительно превышать стоимость простого копирования небольшой строки. Для меня небольшая оптимизация буфера имеет гораздо больше смысла, чтобы в таких случаях избежать выделения кучи вместо копий строк.

Однако, если у вас есть более здоровенный объект, например, андроид, и вы хотите скопировать его и просто заменить его кибернетическую руку, COW кажется вполне разумным способом сохранить изменяемый синтаксис, избегая при этом необходимости глубокого копирования всего Android только для дать копию уникального оружия. Делать его просто неизменным в качестве постоянной структуры данных в этот момент может быть лучше, но «частичное COW», применяемое к отдельным частям Android, кажется разумным для этих случаев.

В таком случае две копии андроида будут иметь один и тот же торс, ноги, ступни, голову, шею, плечи, таз и т. Д. Единственная информация, которая будет отличаться между ними и не будет использоваться, это рука, которая была сделана уникальный для второго андроида при перезаписи его руки.