¿Es razonable usar std :: basic_string <t> como un búfer contiguo cuando se dirige a C++ 03?

Question

Sé que en C++ 03, técnicamente no es necesario que la plantilla std::basic_string tenga memoria contigua. Sin embargo, tengo curiosidad de cuántas implementaciones existen para los compiladores modernos que realmente aprovechan esta libertad. Por ejemplo, si uno quiere usar basic_string para recibir los resultados de alguna API de C (como en el ejemplo a continuación), parece tonto asignar un vector solo para convertirlo en una cadena inmediatamente.

Ejemplo:

DWORD valueLength = 0; 
DWORD type; 
LONG errorCheck = RegQueryValueExW(
     hWin32, 
     value.c_str(), 
     NULL, 
     &type, 
     NULL, 
     &valueLength); 

if (errorCheck != ERROR_SUCCESS) 
    WindowsApiException::Throw(errorCheck); 
else if (valueLength == 0) 
    return std::wstring(); 

std::wstring buffer; 
do 
{ 
    buffer.resize(valueLength/sizeof(wchar_t)); 
    errorCheck = RegQueryValueExW(
      hWin32, 
      value.c_str(), 
      NULL, 
      &type, 
      &buffer[0], 
      &valueLength); 
} while (errorCheck == ERROR_MORE_DATA); 

if (errorCheck != ERROR_SUCCESS) 
    WindowsApiException::Throw(errorCheck); 

return buffer; 

sé código como este podría reducir ligeramente la portabilidad, ya que implica que es contigua std::wstring - pero me pregunto hasta qué punto no portables que hace este código. Dicho de otra manera, ¿cómo pueden los compiladores aprovechar la libertad que tiene la memoria no contigua?

---

EDIT: Actualicé esta pregunta para mencionar C++ 03. Los lectores deben tener en cuenta que al apuntar a C++ 11, el estándar ahora requiere que basic_string sea contiguo, por lo que la pregunta anterior no es un problema al apuntar a ese estándar.

Answer 1

Considero que es bastante seguro asumir que std :: string asigna su almacenamiento de forma contigua.

En la actualidad, todas las implementaciones conocidas de std::string asignan espacio contiguamente.

Por otra parte, el actual proyecto de C++ 0x (N3000) [Editar: Advertencia, enlace directo a gran PDF] requiere que el espacio se asignará de manera contigua (§21.4.1/5):

El carbón -like objetos en un objeto basic_string se deben almacenar contiguamente. Es decir, para cualquier basic_string objeto s, la identidad & * (s.begin() + n) == & * s.begin() + n ocupará para todos los valores de n, tales que 0 < = n < s.size().

Como tal, las posibilidades de una implementación actual o futura de std::string usando el almacenamiento no contiguo son esencialmente nulas.

Answer 2

El resultado es indefinido y no lo haría. El costo de leer en un vector y luego convertirlo en una cadena es trivial en los montones modernos de C++. VS el riesgo de que su código fallezca en Windows 9

también, ¿no necesita un const_cast en & buffer [0]?

Answer 3

Por supuesto, asignar un vector aquí es una tontería. Usar std :: wstring aquí tampoco es sabio. Es mejor usar una matriz de caracteres para llamar a los winapi. construir un wstring al devolver el valor.

Answer 4

Hace un tiempo hubo una pregunta acerca de ser capaz de escribir en el almacenamiento para un std::string como si se tratara de una gran variedad de personajes, y que giraba en torno a si el contenido de un std::string eran contiguas:

• Is it legal to write to std::string?

Mi respuesta indicó que de acuerdo a una pareja bien fuentes (Herb Sutter y Matt Austern) la corriente estándar de C++ requiere std::string para almacenar su contigua de datos bajo ciertas condiciones (una vez que se llama aconsiderado 10 suponiendo str es un std::string) y ese hecho prácticamente obliga a la implementación.

Básicamente, si combina las promesas hechas por string::data() y string::operator[]() concluye que &str[0] necesita devolver un búfer contiguo. Por lo tanto, Austern sugiere que el comité simplemente lo haga explícito, y aparentemente eso es lo que sucederá en el estándar 0x (¿o lo están llamando el estándar 1x ahora?).

De manera estricta, una implementación no tiene que implementar std::string usando almacenamiento contiguo, pero tiene que hacerlo prácticamente a pedido. Y su código de ejemplo lo hace al pasar en &buffer[0].

Enlaces:

• Herb Sutter's comment
• Matt Austern's C++ Standard Library Defect Report
• previous SO answer

Answer 5

Editar: Quiere llamar &buffer[0], no buffer.data(), porque devuelve un [] no const referencia y hace notificar al objeto que su contenido puede cambiar inesperadamente.

---

Sería más limpio que hacer buffer.data(), pero debe preocuparse menos de memoria contigua de memoria compartida entre las estructuras. Las implementaciones string pueden y deben esperar que se les informe cuando se modifica un objeto. string::data específicamente requiere que el programa no modifique el búfer interno devuelto.

MUCHAS altas posibilidades de que alguna implementación creará un búfer para todas las cadenas sin inicializar además de tener la longitud establecida en 10 o lo que sea.

Utilice un vector o incluso una matriz con new[]/delete[]. Si realmente no puede copiar el búfer, inicialice legalmente la cadena a algo único antes de cambiarlo.