Manejo de cadenas en C++

Una implementación de copia en escritura significa

cadena a = "¡hola!" ; cadena b = a ; // Constructor de copia

En realidad, no copia el contenido de aa b; en cambio, ambas cadenas comparten su contenido y se incrementa un contador de referencias sobre el contenido. La copia propiamente dicha se pospone hasta que una operación de modificación, como cambiar un carácter, hace que el contenido de las cadenas sea diferente.

La estrategia de copia en escritura fue permitida deliberadamente por el estándar inicial de C++ porque std::stringse consideró una optimización útil y fue utilizada por casi todas las implementaciones. ^{[ 8 ]} Sin embargo, hubo errores, en particular que operator[]devolvía una referencia no constante para facilitar la portabilidad de código C como s[5] = 'a', y tenía que activar una copia. El multihilo provocó que las optimizaciones (como no copiar cuando el contador de referencias es uno) fallaran ^{[ 10 ]} y en los procesadores modernos el bloqueo necesario para examinar o cambiar el contador de referencias es más costoso que copiar una cadena pequeña. ^{[ 11 ]}

Esto provocó que las implementaciones, primero MSVC y luego GCC, se alejaran de la copia en escritura. ^{[ 12 ]} La optimización finalmente se prohibió en C++11 . ^{[ 13 ]}

La mayoría de las implementaciones ahora utilizan la Optimización de Cadenas Cortas (SSO), donde las cadenas de menos de 16 (o 23) bytes se almacenan en el objeto de cadena y no se asigna ningún búfer. ^{[ 14 ]} Esto es significativamente más rápido que el conteo de referencias, ya que una proporción sorprendente de cadenas son así de cortas, y la asignación de búfer es extremadamente costosa en comparación con la copia de bloques de memoria locales.

A diferencia de otros lenguajes, como Javajava.lang.String o C#System.String , las cadenas de C++ siempre son mutables, ya que las constantes de cadena entre comillas terminadas en nulo cumplían la mayor parte de la función de una clase no mutable. C++ requiere que el código siguiente cree una copia de la cadena, lo cual es bastante lento en comparación con pasar un puntero, incluso si se utilizan contadores de referencias de copia en escritura. ^{[ 11 ]}

importar std ;usando std :: string ;void outputString ( string s ) { std :: print ( "{}" , s ); }// ... cadena s = "..." ; outputString ( s ); // hace una copia de s outputString ( "esta es una cadena literal" ); // copia la cadena, a veces dos veces

Aunque el compilador podría optimizar esto para funciones en línea, pocos dependían de esto y casi siempre las cadenas se pasan como una referencia constante : ^{[ 15 ]} La conversión desde una constante de cadena también requería la construcción de una temporal std::stringy era lenta, lo que generalmente llevaba a funciones sobrecargadas:

importar std ;usando std :: string ;void outputString ( const string & s ) { std :: print ( "{}" , s ); }void outputString ( const char * s ) { std :: print ( "{}" , s ); }// ... cadena s = "..." ; outputString ( s ); // no copia s, pasa un puntero/referencia outputString ( "esta es una cadena literal" ); // llama a la sobrecarga y pasa un puntero sin procesar

El estándar C++17 agrega la std::string_viewclase ^{[ 16 ]} que es solo un puntero y una longitud a datos de solo lectura, y es un reemplazo directo para un temporalstd::string inmutable y hace que los argumentos pasados ​​por valor sean más rápidos que cualquiera de los ejemplos anteriores:

importar std ;using std :: string ; using std :: string_view ;void outputString ( string_view sv ) { std :: print ( "{}" , s ); }// ... cadena s = "..." ; outputString ( s ); // un nivel menos de indirección outputString ( "esta es una cadena literal" ); // además, el compilador puede optimizar eliminando la necesidad de usar strlen()

Todas las funciones de una biblioteca que toman un argumento de cadena deben reescribirse para aprovechar esto en C++17, ya que la conversión de std::string_viewa std::stringsigue siendo costosa.

Se puede construir una vista de cadena a partir de un literal de cadena utilizando el operador: por ejemplo, ^{[ 17 ]}std::literals::string_view_literals::operator""svstring_viewsv="Hello, world!"sv;

std::stringes un typedef para una instancia particular de la std::basic_string<CharT, Traits, Alloc>clase plantilla . ^{[ 18 ]} Su definición se encuentra en el encabezado <string> :

espacio de nombres std { usando cadena = cadena_básica < carácter > ; }

Hay una clase similar std::wstring, que consta de wchar_t , y se usa con mayor frecuencia para almacenar texto UTF-16 en Windows y UTF-32 en la mayoría de las plataformas tipo Unix . Sin embargo, el estándar C++ no impone ninguna interpretación como puntos de código Unicode o unidades de código en estos tipos y ni siquiera garantiza que un contenga más bits que un . ^{[ 19 ]} Para resolver algunas de las incompatibilidades resultantes de las propiedades de , C++11 agregó dos nuevas clases: y (compuestas por los nuevos tipos y ), que son el número dado de bits por unidad de código en todas las plataformas. ^{[ 20 ]} C++11 también agregó nuevos literales de cadena de "caracteres" de 16 bits y 32 bits y sintaxis para colocar puntos de código Unicode en cadenas terminadas en nulo (estilo C). ^{[ 21 ]}wchar_tcharwchar_tstd::u16stringstd::u32stringchar16_tchar32_t

Se garantiza que A std::basic_string<CharT, Traits, Alloc>es especializable para cualquier tipo con una std::char_traits<CharT>estructura que lo acompañe. A partir de C++11, solo se requiere implementar las especializaciones char, wchar_t, char16_ty . ^{[ 22 ]} En , los dos parámetros de plantilla y tienen los valores predeterminados de y por defecto.char32_tstd::basic_string<CharT, Traits, Alloc>TraitsAllocstd::char_traits<CharT>std::allocator<CharT>

A std::basic_stringtambién es un contenedor de la biblioteca estándar y, por lo tanto, los algoritmos de la biblioteca estándar se pueden aplicar a las unidades de código en las cadenas.

El diseño std::stringha sido presentado como un ejemplo de diseño monolítico por Herb Sutter , quien considera que de las 103 funciones miembro de la clase en C++98, 71 podrían haberse desacoplado sin pérdida de eficiencia de implementación. ^{[ 23 ]}