O objetivo de todo e qualquer tipo de proposta de "referência de cadeia" e "referência de matriz" é evitar a cópia de dados que já pertencem a outro lugar e dos quais é necessária apenas uma visão não mutante. A string_view
questão em questão é uma dessas propostas; havia ligações anteriores string_ref
e array_ref
também.
A idéia é sempre armazenar um par de ponteiro para o primeiro elemento e tamanho de alguma matriz ou sequência de dados existente .
Essa classe de identificador de exibição poderia ser distribuída mais barata por valor e ofereceria operações de substringing baratas (que podem ser implementadas como simples incrementos de ponteiro e ajustes de tamanho).
Muitos usos de cadeias de caracteres não requerem a propriedade real das cadeias de caracteres, e a cadeia em questão muitas vezes já será de propriedade de outra pessoa. Portanto, existe um potencial genuíno para aumentar a eficiência, evitando cópias desnecessárias (pense em todas as alocações e exceções que você pode salvar).
As cadeias C originais estavam sofrendo com o problema de o terminador nulo fazer parte das APIs da cadeia e, portanto, não era possível criar facilmente subseqüências sem alterar a cadeia subjacente (à la strtok
). No C ++, isso é facilmente resolvido armazenando o comprimento separadamente e envolvendo o ponteiro e o tamanho em uma classe.
O principal obstáculo e divergência da filosofia da biblioteca padrão C ++ em que consigo pensar é que essas classes de "exibição referencial" têm semântica de propriedade completamente diferente do restante da biblioteca padrão. Basicamente, tudo o mais na biblioteca padrão é incondicionalmente seguro e correto (se compilar, está correto). Com classes de referência como essa, isso não é mais verdade. A correção do seu programa depende do código do ambiente que usa essas classes. Portanto, é mais difícil verificar e ensinar.