Méritos da semântica de copiar na gravação

Pergunto-me que méritos possíveis o copy-on-write tem? Naturalmente, não espero opiniões pessoais, mas cenários práticos do mundo real em que pode ser técnica e praticamente benéfica de maneira tangível. Por tangível, quero dizer algo mais do que poupar a digitação de um &personagem.

Para esclarecer, essa pergunta está no contexto de tipos de dados, em que a construção de atribuição ou cópia cria uma cópia superficial implícita, mas as modificações nela criam uma cópia profunda implícita e aplicam as alterações a ela, em vez do objeto original.

A razão pela qual estou perguntando é que não consigo encontrar nenhum mérito de ter a COW como um comportamento implícito padrão. Eu uso o Qt, que implementou o COW para muitos tipos de dados, praticamente todos os quais possuem algum armazenamento alocado dinamicamente subjacente. Mas como isso realmente beneficia o usuário?

Um exemplo:

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"

O que ganhamos usando o COW neste exemplo?

Se tudo o que pretendemos fazer é usar operações const, s1é redundante e pode ser usado s.

Se pretendemos alterar o valor, o COW apenas atrasa a cópia do recurso até a primeira operação não const, ao custo (ainda que mínimo) de incrementar a contagem de ref para o compartilhamento implícito e a desanexação do armazenamento compartilhado. Parece que toda a sobrecarga envolvida na COW é inútil.

Não é muito diferente no contexto da passagem de parâmetros - se você não pretende modificar o valor, passe como referência const; se quiser modificar, faça uma cópia implícita e profunda se não quiser modificar o objeto original ou passe por referência, se desejar modificá-lo. Novamente, o COW parece uma sobrecarga desnecessária que não alcança nada e apenas adiciona uma limitação de que você não pode modificar o valor original, mesmo que queira, pois qualquer alteração será destacada do objeto original.

Portanto, dependendo se você conhece a COW ou não o conhece, pode resultar em código com intenção obscura e sobrecarga desnecessária, ou comportamento completamente confuso que não corresponde às expectativas e deixa você coçando a cabeça.

Para mim, parece que existem soluções mais eficientes e legíveis, se você deseja evitar uma cópia profunda desnecessária ou se pretende fazer uma. Então, onde está o benefício prático da vaca? Suponho que deve haver algum benefício, pois é usado em uma estrutura tão popular e poderosa.

Além disso, pelo que li, o COW agora é explicitamente proibido na biblioteca padrão do C ++. Não sei se os truques que vejo nele têm algo a ver com isso, mas, de qualquer forma, deve haver uma razão para isso.

A cópia na gravação é usada em situações em que você frequentemente cria uma cópia do objeto e não a modifica. Nessas situações, ele se paga.

Como você mencionou, você pode passar um objeto const e, em muitos casos, isso é suficiente. No entanto, const apenas garante que o chamador não pode modificá-lo (a menos que const_cast, é claro). Ele não lida com casos de multithreading e não lida com casos em que há retornos de chamada (que podem alterar o objeto original). Passar um objeto COW por valor coloca os desafios de gerenciar esses detalhes no desenvolvedor da API, e não no usuário da API.

As novas regras para C + 11 proíbem COW, std::stringem particular. Os iteradores em uma cadeia de caracteres devem ser invalidados se o buffer de backup for desanexado. Se o iterador estava sendo implementado como um char*(ao contrário de a string*e um índice), esses iteradores não são mais válidos. A comunidade C ++ teve que decidir com que frequência os iteradores poderiam ser invalidados, e a decisão foi que operator[]não deveria ser um desses casos. operator[]em um std::stringretorna a char&, que pode ser modificado. Portanto, operator[]seria necessário desanexar a sequência, invalidando iteradores. Isso foi considerado um comércio ruim e, ao contrário de funções como end()e cend(), não há como solicitar a versão operator[]const, com exceção de const, lançando a string. ( relacionado ).

A vaca ainda está viva e bem fora do STL. Em particular, achei muito útil nos casos em que não é razoável para um usuário de minhas APIs esperar que exista algum objeto pesado por trás do que parece ser um objeto muito leve. Talvez eu queira usar o COW em segundo plano para garantir que eles nunca precisem se preocupar com esses detalhes de implementação.

Para seqüências de caracteres e coisas do tipo, isso parece pessimizar casos de uso mais comuns do que não, pois o caso comum de seqüências de caracteres geralmente é de seqüências pequenas, e a sobrecarga do COW tende a compensar muito o custo de simplesmente copiar a sequência de caracteres pequena. Uma pequena otimização de buffer faz muito mais sentido para mim, para evitar a alocação de heap nesses casos, em vez das cópias de string.

Porém, se você tem um objeto mais pesado, como um andróide, e deseja copiá-lo e apenas substituir seu braço cibernético, a COW parece bastante razoável como uma maneira de manter uma sintaxe mutável, evitando a necessidade de copiar profundamente todo o andróide apenas para dê à cópia um braço único. Torná-lo imutável como uma estrutura de dados persistente nesse ponto pode ser superior, mas uma "COW parcial" aplicada em partes individuais do android parece razoável para esses casos.

Nesse caso, as duas cópias do androide compartilhariam / instariam o mesmo tronco, pernas, pés, cabeça, pescoço, ombros, pélvis etc. Os únicos dados que seriam diferentes entre eles e não compartilhados são o braço que foi feito exclusivo para o segundo androide sobrescrevendo seu braço.