El propósito de todos y cada uno de los tipos de propuestas de "referencia de cadena" y "referencia de matriz" es evitar copiar datos que ya son propiedad de otro lugar y de los cuales solo se requiere una vista no mutante. La string_viewen cuestión es una de esas propuestas; hubo otros llamados string_refy array_reftambién.
La idea siempre es almacenar un par de puntero al primer elemento y el tamaño de una matriz o cadena de datos existente .
Tal clase de manejador de vista podría transmitirse de forma económica por valor y ofrecería operaciones de subcadena baratas (que pueden implementarse como simples incrementos de puntero y ajustes de tamaño).
Muchos usos de cadenas no requieren la posesión real de las cadenas, y la cadena en cuestión a menudo ya será propiedad de otra persona. Por lo tanto, existe un verdadero potencial para aumentar la eficiencia al evitar copias innecesarias (piense en todas las asignaciones y excepciones que puede guardar).
Las cadenas C originales sufrían el problema de que el terminador nulo formaba parte de las API de cadena, por lo que no podía crear subcadenas fácilmente sin mutar la cadena subyacente (a la strtok). En C ++, esto se resuelve fácilmente almacenando la longitud por separado y envolviendo el puntero y el tamaño en una clase.
El principal obstáculo y divergencia de la filosofía de la biblioteca estándar de C ++ que se me ocurre es que tales clases de "vista referencial" tienen una semántica de propiedad completamente diferente del resto de la biblioteca estándar. Básicamente, todo lo demás en la biblioteca estándar es incondicionalmente seguro y correcto (si se compila, es correcto). Con clases de referencia como esta, eso ya no es cierto. La exactitud de su programa depende del código ambiental que utiliza estas clases. Eso es más difícil de verificar y enseñar.