¿Qué es mejor para los literales de cadena, cadena estándar o matriz de caracteres?¿Cuál usar const char [] o const std :: string?
quiero decir para cadenas constantes, dicen
const char name[] = "so"; //or to use
const string name = "so";
Para cadenas literales, y solo para constantes de cadena que provienen de literales, usaría const char[]. La principal ventaja de std::string es que tiene administración de memoria de forma gratuita, pero eso no es un problema con los literales de cadena.
Es el tipo real del literal de todos modos, y se puede usar directamente en cualquier API que requiera las antiguas cadenas nulas del estilo C o las cadenas C++ (se activa la conversión implícita). También obtiene una implementación de tamaño de tiempo de compilación utilizando la matriz en lugar del puntero.
Ahora, al definir las interfaces de función, e incluso si se intentan pasar las constantes, preferiría std::string en lugar de const char*, ya que en este último caso el tamaño se pierde y es posible que deba volver a calcularse.
Según mi propia experiencia. Me anticipé a escribir .c_str() en todas y cada una de las llamadas a la biblioteca de registro (que usaba argumentos variables) para cadenas literales con mensajes de información/error.
Usted debe usar lo que es más apropiado para usted. Si no hay requisitos especiales, usaría std::string porque funciona la memoria.
Para cadenas literales, usaría const char*. La razón contra const char[] es que podría usar const char* para inicializar otra constante. Compruebe el código siguiente:
const char str1[] = "str1";
const char* str11 = "str11";
const char str2[] = str1; // <<< compile error
const char* str22 = str11; // <<< OK
literales de cadena tiene una duración de almacenamiento estático (de acuerdo con 2.13.4/2) de manera puntero const char* será válida hasta la finalización del programa.
¿Qué estás haciendo con él? ¿Qué esperan tus métodos?
const char es más ligero en el almacenamiento, pero no tiene el poder de std :: string, o la seguridad al usarlo. Sin embargo, si tiene muchas API C, puede ser la opción más juiciosa.
std :: string sería la opción preferida.
.c_str() es tu amigo :) – JPvdMerwe
@JPvdMerwe: theatrus es correcto. Si todo lo que estás haciendo es pasar una cadena constante a las funciones que requieren un 'const char *', no tiene sentido usar 'std :: string' /' .c_str() '. Una matriz 'const' de' char' no tiene costo de llamada al constructor y se puede pasar directamente a las funciones, lo que hace que sea más barato de construir y más barato pasar a funciones que un 'std :: string'. –
Sí, para literales de cadenas, estoy totalmente de acuerdo, no tiene sentido perder el tiempo de su procesador. – JPvdMerwe
Tiendo a favor de const std::string sobre const char * para cadenas literales. Debido a que al pasar literales de cadena a las funciones que toman const std::string & se creará cadena de forma silenciosa cada vez que se llamen en lugar de solo una. Sin embargo, si utilizo principalmente el literal con funciones esperando un const char * lo usaré en su lugar.
Tiendo a favor de std::string para apis.
Por supuesto, si uso unicode, uso std::wstring y wchar_t.
Hice la misma suposición sobre Unicode, pero esto es interesante: http://utf8everywhere.org/. Resulta que wchar_t es una especie de reliquia de un tiempo más simple en la historia de unicode, al igual que la API de Win32 que es WCHAR nativa. La vida puede ser mejor si solo te apegas a UTF-8 y std :: string. – terriblememory
Y es más rápido en muchas implementaciones de STL gracias a un mecanismo de copia en escritura si utiliza las mismas cadenas en muchos lugares diferentes, lo que también hace que sea más fácil de usar que las cadenas simples de C. Además de esto, si necesitas soportar muchos idiomas, prefiero usar std :: wstring. – jdehaan
@jdehaan: Me sorprendería si hay (m) cualquier implementación de biblioteca estándar (no implementaciones STL, ya que 'std :: string' no era parte de la STL) que todavía hace COW. En entornos de MT esto generalmente se convierte en una pesimismo. Creo que la optimización de cadenas pequeñas (cadenas pequeñas no se asignan en el montón, pero en la pila) es lo que comúnmente se prefiere ahora. – sbi
La copia en escritura se está eliminando (si todavía está presente) en la mayoría de las implementaciones. Tiene problemas en entornos multiproceso, ya que algunas operaciones que parecen seguras para subprocesos desde el punto de vista del usuario (se refieren a diferentes std :: string) pueden no ser seguras para subprocesos. Considere una cadena que se copia con cada copia pasada a diferentes hilos para su modificación. Cada hilo tiene su propia cadena, no hay objetos compartidos, pero de hecho puede haber una condición de carrera en la implementación interna de 'copiar con escritura'. Agregar un mecanismo de bloqueo a la biblioteca lo convierte en más lento que una implementación simple en muchos casos. –