Usos Prácticos para el " Patrón de Plantilla Curiosamente Recurrente"

También es especialmente útil para mixins (con lo que me refiero a las clases que heredas para proporcionar funcionalidad) que a su vez necesitan saber en qué tipo están operando (y por lo tanto necesitan ser plantillas).

En Effective C++, Scott Meyers proporciona como ejemplo una plantilla de clase NewHandlerSupport. Esto contiene un método estático para sobreescribir el nuevo manejador para una clase en particular (de la misma manera que std::set_new_handler lo hace para el operador predeterminado new), y un operador nuevo que utiliza el controlador. Para proporcionar un manejador por tipo, la clase padre necesita saber en qué tipo está actuando, por lo que necesita ser una plantilla de clase. El parámetro template es la clase hija.

Realmente no podría hacer esto sin CRTP, ya que necesita que la plantilla NewHandlerSupport se instancie por separado, con un miembro de datos estático separado para almacenar el new_handler actual, por clase que lo usa.

Obviamente todo el ejemplo es extremadamente no-hilo seguro, pero ilustra el punto.

Meyers sugiere que el CRTP podría considerarse como "Hazlo Por mí". Diría que este es generalmente el caso de cualquier mixin, y CRTP se aplica en el caso en el que necesita una plantilla mixin en lugar de solo una clase mixin.

El CRTP se vuelve mucho menos curioso si se considera que el tipo de subclase que se pasa a la superclase solo es necesario en el momento de la expansión del método. Entonces todos los tipos están definidos. Solo necesita el patrón para importar el tipo de subclase simbólico a la superclase, pero es solo una declaración hacia adelante - como todos los tipos de param de plantilla formal son por definición - en lo que respecta a la superclase.

Usamos en una forma algo modificada, pasando la subclase en una estructura de tipo traits a la superclase para hacer posible que la superclase devuelva objetos del tipo derivado. La aplicación es una biblioteca para cálculo geométrico (puntos, vectores, líneas, cajas ) donde toda la funcionalidad genérica se implementa en la superclase, y la subclase solo define un tipo específico: CFltPoint hereda de TGenPoint. También CFltPoint existía antes de TGenPoint, por lo que la subclase era una forma natural de refactorizar esto.

Generalmente se usa para patrones polimórficos donde no es necesario poder elegir la clase derivada en tiempo de ejecución, solo en tiempo de compilación. Esto puede ahorrar la sobrecarga de la llamada a la función virtual en tiempo de ejecución.

Para un uso real de la biblioteca de CRTP, mira ATL y WTL (wtl.sf.net). Se utiliza ampliamente allí para el polimorfismo en tiempo de compilación.

Se siente como C macro: aproveche que la macro no se compila en el momento de la definición, sino en el momento del uso.

#define CALL_THE_RIGHT_FOO foo()

Archivo A:

static void foo() {
   // do file A thing
}
...
CALL_THE_RIGHT_FOO
...

Archivo A:

static void foo() {
   // do file B thing
}
...
CALL_THE_RIGHT_FOO
...

El patrón de uso de la plantilla que está describiendo nos permite "llamar al foo correcto" en la plantilla padre, posponiendo la definición de qué es exactamente el foo correcto hasta que se instancie la plantilla. Excepto en este caso es la distinción entre ClassA:: foo y ClassB:: foo basado en la valor de T en Padre.