¿Cuándo debo usar string_view en una interfaz?

Estoy usando una biblioteca interna que fue diseñada para imitar una biblioteca C ++ propuesta , y en algún momento en los últimos años veo que su interfaz cambió de usar std::stringa string_view.

Así que obedientemente cambio mi código, para adaptarme a la nueva interfaz. Desafortunadamente, lo que tengo que pasar es un parámetro std :: string, y algo que es un valor de retorno std :: string. Entonces mi código cambió de algo como esto:

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   api.setup (p1, special_number_to_string(p2));
}

a

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   const std::string p2_storage(special_number_to_string(p2));
   api.setup (string_view(&p1[0], p1.size()), string_view(&p2_storage[0], p2_storage.size()));
}

Yo realmente no veo lo que este cambio me compró como el cliente de API, que no sea más código (posiblemente a meter la pata). La llamada a la API es menos segura (debido a que la API ya no posee el almacenamiento para sus parámetros), probablemente guardó el trabajo de mi programa 0 (debido a las optimizaciones de movimiento que los compiladores pueden hacer ahora), e incluso si ahorrara trabajo, eso solo sería un par de asignaciones que no se realizarán y nunca se realizarán después del inicio o en un gran bucle en alguna parte. No es para esta API.

Sin embargo, este enfoque parece seguir los consejos que veo en otros lugares, por ejemplo, esta respuesta :

Por otro lado, desde C ++ 17 debe evitar pasar un const std :: string & a favor de un std :: string_view:

Encuentro sorprendente este consejo, ya que parece estar abogando por el reemplazo universal de un objeto relativamente seguro por uno menos seguro (básicamente un puntero y una longitud glorificados), principalmente con fines de optimización.

Entonces, ¿cuándo se debe usar string_view y cuándo no?

1. ¿La funcionalidad que toma el valor necesita tomar posesión de la cadena? Si es así, use std::string(no const, no ref). Esta opción le da la opción de moverse explícitamente en un valor también si sabe que nunca más se usará en el contexto de la llamada.
2. ¿La funcionalidad solo lee la cadena? Si es así, use std::string_view(const, no ref) esto se debe a que string_viewpuede manejar std::stringy char*fácilmente sin problemas y sin hacer una copia. Esto debería reemplazar todos los const std::string&parámetros.

Finalmente, nunca deberías necesitar llamar al std::string_viewconstructor como eres. std::stringtiene un operador de conversión que maneja la conversión automáticamente.

A std::string_viewtrae algunos de los beneficios de a const char*a C ++: a diferencia de std::string, string_view

• no posee memoria,
• no asigna memoria,
• puede apuntar a una cadena existente en algún desplazamiento, y
• tiene un nivel menos de puntero indirecto que a std::string&.

Esto significa que string_view a menudo puede evitar copias, sin tener que lidiar con punteros sin formato.

En el código moderno, std::string_viewdebería reemplazar casi todos los usos de los const std::string&parámetros de función. Esto debería ser un cambio compatible con la fuente, ya que std::stringdeclara un operador de conversión a std::string_view.

El hecho de que una vista de cadena no ayude en su caso de uso específico en el que necesita crear una cadena de todos modos no significa que sea una mala idea en general. La biblioteca estándar de C ++ tiende a optimizarse para generalidad más que para conveniencia. El argumento "menos seguro" no se cumple, ya que no debería ser necesario crear la vista de cadena usted mismo.

Encuentro sorprendente este consejo, ya que parece estar abogando por el reemplazo universal de un objeto relativamente seguro por uno menos seguro (básicamente un puntero y una longitud glorificados), principalmente con fines de optimización.

Creo que esto es un poco malentendido el propósito de esto. Si bien es una "optimización", realmente deberías pensar en ello como liberarte de tener que usar a std::string.

Los usuarios de C ++ han creado docenas de diferentes clases de cadenas. Clases de cadenas de longitud fija, clases optimizadas para SSO con el tamaño del búfer como un parámetro de plantilla, clases de cadenas que almacenan un valor hash utilizado para compararlas, etc. Algunas personas incluso usan cadenas basadas en COW. Si hay algo que a los programadores de C ++ les encanta hacer, es escribir clases de cadena.

Y eso ignora las cadenas que son creadas y propiedad de las bibliotecas C. Desnudo char*, tal vez con un tamaño de algún tipo.

Entonces, si está escribiendo alguna biblioteca y toma una const std::string&, el usuario ahora tiene que tomar la cadena que estaba usando y copiarla en a std::string. Tal vez docenas de veces.

Si desea acceder a std::stringla interfaz específica de la cadena, ¿por qué debería copiar la cadena? Eso es un desperdicio.

Las razones principales para no tomar a string_viewcomo parámetro son:

1. Si su objetivo final es pasar la cadena a una interfaz que toma una cadena terminada en NUL ( fopen, etc.). std::stringestá garantizado para ser NUL terminado; string_viewno lo es Y es muy fácil substraer una vista para que no tenga terminación NUL; sub-encadenar un std::stringcopiará la subcadena a cabo en un rango NUL terminados.

   Escribí un tipo especial de estilo string_view terminado en NUL para exactamente este escenario. Puede realizar la mayoría de las operaciones, pero no las que rompen su estado terminado por NUL (recorte desde el final, por ejemplo).

2. Problemas de por vida. Si realmente necesita copiar eso std::stringo si la matriz de caracteres sobrevive a la llamada a la función, es mejor declarar esto por adelantado tomando un const std::string &. O simplemente std::stringcomo un parámetro de valor. De esa manera, si ya tienen una cadena de este tipo, puede reclamar su propiedad de inmediato, y la persona que llama puede moverse a la cadena si no necesita guardar una copia.