La incompatibilidad proviene del rasgo de tipo std::uses_allocator, que evalúa a false para la combinación de std::string y std::pmr::polymorphic_allocator. std::string codifica su allocator_type como std::allocator<char>, mientras que std::pmr::vector proporciona std::pmr::polymorphic_allocator<char>; estos son tipos de clase distintos y no relacionados, sin ninguna conversión implícita o relación de herencia. Cuando el contenedor construye elementos, consulta std::uses_allocator_v<T, Alloc> para determinar si pasar el asignador como argumento del constructor; dado que esta comprobación falla, el vector trata a std::string como si no fuera consciente del asignador e invoca su constructor predeterminado, que utiliza internamente new y delete globales, sin importar la fuente de memoria del vector.
static_assert(!std::uses_allocator_v<std::string, std::pmr::polymorphic_allocator<char>>); // std::pmr::vector NO pasará su asignador a std::string
Durante la optimización de un motor de cálculo de riesgo financiero, refactorizamos un camino caliente para usar std::pmr::monotonic_buffer_resource respaldado por memoria de pila para eliminar la contención del montón. Declaramos std::pmr::vectorstd::string temp_symbols esperando que todos los nombres de símbolos temporales se extrajeran del búfer monótono, pero la evaluación del rendimiento reveló llamadas inesperadas a malloc dentro de los constructores de std::string, indicando que la fuente de memoria estaba siendo completamente eludida.
Consideramos construir manualmente cada std::string con un std::pmr::polymorphic_allocator explícito pasado a su constructor, pero esto requería exponer detalles de asignación a la lógica comercial de nivel superior y impedía el uso de modificadores convenientes como emplace_back. Otro enfoque consistió en crear un envoltorio de cadena personalizado que heredara de std::string y aceptara un asignador polimórfico, pero esto violaba el principio de sustitución de Liskov y introducía riesgos de división de objetos durante la realocación del contenedor. Finalmente, reemplazamos std::string con std::pmr::string (un alias para std::basic_string<char, std::char_traits<char>, std::pmr::polymorphic_allocator<char>>), que declara inherentemente allocator_type como la variante polimórfica. Esto permitió que el vector propagara automáticamente su asignador a través del protocolo uses_allocator, eliminando todas las asignaciones en el montón en el camino caliente y reduciendo la latencia de microsegundos a cientos de nanosegundos.
¿Cómo se puede hacer que una clase personalizada sea compatible con std::pmr::polymorphic_allocator si realiza asignaciones dinámicas internas, dado que simplemente aceptar un parámetro de asignador en su constructor no es suficiente?
Una clase debe anunciar explícitamente su conocimiento del asignador al exponer un alias de tipo público allocator_type convertible desde el asignador en uso, o al proporcionar un constructor cuyo primer parámetro sea std::allocator_arg_t y el segundo parámetro sea el tipo de asignador, combinado con la especialización de std::uses_allocator<ClassName, Alloc> para derivar de std::true_type. Sin esta publicidad explícita, std::pmr::vector asume que la clase no es consciente del asignador y la construye a través de la inicialización predeterminada, haciendo que cualquier asignación interna eluda la fuente de memoria polimórfica.
¿Por qué std::allocator_traits<std::pmr::polymorphic_allocator<T>>::rebind_alloc<U> no resuelve la incompatibilidad entre std::pmr::vector y std::string?
Volver a vincular produce un std::pmr::polymorphic_allocator<U>, que sigue siendo incompatible con std::allocator<U> porque son tipos concretos distintos sin relación de conversión. El mecanismo std::uses_allocator requiere que el allocator_type del elemento sea el mismo que el del tipo de asignador del contenedor o convertible desde este, no simplemente volviéndose a vincular a un tipo de valor diferente; ya que std::string codifica std::allocator, volver a vincular el asignador del contenedor no cambia el tipo de asignador esperado por el elemento.
¿Qué riesgo específico de duración surge al usar std::pmr::monotonic_buffer_resource con std::pmr::string, y por qué es más difícil detectar esto que con los asignadores estándar?
Debido a que std::pmr::polymorphic_allocator es un tipo borrado y almacena un puntero a un std::pmr::memory_resource base, el compilador no puede hacer cumplir las restricciones de duración en tiempo de compilación. Cuando un std::pmr::string que referencia un monotonic_buffer_resource basado en stack se mueve o copia a un alcance de vida más largo, el puntero a la fuente de memoria se vuelve colgante; a diferencia de std::allocator que típicamente usa el montón global (siempre válido), acceder a la cadena después de la destrucción del búfer resulta en uso después de la liberación. Los analizadores estáticos tienen dificultades para detectar esto porque la interfaz virtual do_allocate/do_deallocate oculta la duración de la fuente subyacente del sistema de tipos.