¿Por qué la interfaz C++ 03 no es estándar para consultar los tipos de miembro para asignadores utilizados en C++ 0x? ¿Cuáles son los casos de uso donde los tipos de miembros no son suficientes?¿Cuál es el propósito de allocator_traits <T> en C++ 0x?
No estoy familiarizado con este tipo de cosas ( en absoluto), pero this document parece ser un buen punto de partida para tener una idea sobre la razón de ser de allocator_traits:
La clave de esta propuesta es la definición de un
allocator_traitstipos de plantilla que contiene y funciones miembro estáticas para el uso de asignadores, sustituyendo eficazmente el conceptoAllocatorque se perdió en Frankfurt.
Para explicar allocator_traits en términos de patrón de diseño, su un Adapter para envolver su asignador personalizado que satisface los requerimientos mucho menos la aplicación (sin necesidad de construir, destruir, todas esas typedefs ...) y lo convierte en objeto FlyWeight eso completa el resto del requisito de implementación de Allocator para usted con miembros y tipos estáticos.
Con allocator_traits, solo necesita proporcionar un mínimo de 10 líneas de código para su asignador personalizado, según la página 3 del doc abierto Scoped Allocator Model (por ejemplo, a @icecrime).
Creo que allocator_traits y allocator son un buen ejemplo del mundo real de convertir objetos no FlyWeight en FlyWeight para aliviar la carga de los detalles de la implementación. Es una buena práctica de diseño de API para convertir una clase en FlyWeight que debería haber sido FlyWeight en primer lugar.
Para los programadores de Java, en términos de patrón de diseño, std :: allocator_traits es como las clases privadas de paquete CharacterDataLatin1, ChracterData00, CharacterData0E, 01, 02 ... que hereda de java.lang.CharacterData para proporcionar definición estática y ayudantes Unicode que deben ser compartidas por cada instancia de las clases Character (std :: allocator).
Editar: Otra ventaja de llamar indirectamente a través de su asignador de costumbre allocator_traits es que garantiza la compatibilidad foward (página 3 de Scoped Allocator Model). Número de requirements puede crecer en el futuro, e incluso si no sabe cómo implementar nuevos requisitos para su asignador, esos requisitos ya estarán allí en allocator_traits implementados por el fabricante del compilador. Sabiendo que los contenedores C++ llaman allocator indirectamente por allocator_traits, los contenedores STL que usan su asignador personalizado se beneficiarán de los nuevos requisitos sin la necesidad de que usted cambie su código.
parece bastante tonto para hacer 'automático p = allocator_traits :: asignar (myalloc, n);' en lugar de ' automático p = myalloc.allocate (n);' ya que el primero es el tiempo llamando a este último. ¿Por qué agregaron la interfaz anterior en absoluto? –
@buratinas: a mi entender, para respaldar el [Modelo de adjudicador de alcance] (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf) – icecrime