definicion - ¿Por qué las plantillas de plantillas en C++ no son más un pilar?

plantillas c++ definicion

Question

Uso mucho las plantillas en C ++, pero me pregunto por qué la técnica no se usa más. Parece lo último en reutilización. Esta combinación de potencia y eficiencia es una de las razones por las que realmente amo a C ++ y no puedo verme a mí mismo cambiando a un lenguaje JIT.

Este artículo: http://www.thinkbottomup.com.au/site/blog/C%20%20_Mixins_-_Reuse_through_inheritance_is_good es un buen antecedente si no sabe lo que son y pone el caso tan claramente en términos de reutilización y el rendimiento.

Answer 1

El problema con los mixins es ... la construcción.

class Base1 { public: Base1(Dummy volatile&, int); };
class Base2 { public: Base2(Special const&, Special const&); };

Y ahora, mi super mixin:

template <typename T>
struct Mixin: T {};

¿Te das cuenta del problema aquí? ¿Cómo diablos se supone que debo pasar los argumentos al constructor de la clase base? ¿Qué tipo de constructor debería proponer Mixin ?

Es un problema difícil, y no se resolvió hasta C ++ 11 que mejoró el lenguaje para obtener un reenvío perfecto.

// std::foward is in <utility>
template <typename T>
struct Mixin: T {
template <typename... Args>
explicit Mixin(Args&&... args): T(std::forward<Args>(args...)) {}
};

Nota: los dobles controles son bienvenidos.

Así que ahora podemos usar mixins ... y solo tenemos que cambiar los hábitos de las personas :)

Por supuesto, si realmente queremos es un tema totalmente diferente.

Uno de los problemas con los mixins (que el artículo pobre al que hace referencia se saltan felizmente) es el aislamiento de la dependencia que se pierde por completo ... y el hecho de que los usuarios de LoggingTask están obligados a escribir métodos de plantilla. En bases de código muy grandes, se presta más atención a las dependencias que al rendimiento, porque las dependencias queman los ciclos humanos mientras que el rendimiento solo quema los ciclos de la CPU ... y generalmente son más baratos.

Answer 2

Las plantillas requieren que la implementación sea visible en la unidad de traducción, no solo en el momento del enlace (C ++ 11 aborda eso si solo usará un puntero o una referencia a las instancias). Este es un problema importante para el código de bajo nivel en entornos empresariales: los cambios en la implementación activarán (podría o no ser automáticamente) un número masivo de bibliotecas y clientes para recompilar, en lugar de simplemente volver a vincularlos.

Además, cada creación de plantillas crea un tipo distinto, lo que significa que las funciones destinadas a funcionar en cualquiera de las instancias de la plantilla tienen que ser capaces de aceptarlas, ya sea forzándolas a tener una plantilla, o necesitan una forma de transferencia al polimorfismo en tiempo de ejecución (que a menudo es bastante fácil de hacer: solo se necesita una clase base abstracta que exprese el conjunto de operaciones admitidas, y alguna función "consígame un descriptor de acceso" que devuelva un objeto derivado con un puntero a la creación de instancias de la plantilla y las entidades relacionadas en la tabla de envío virtual) .

De todos modos, estos problemas son generalmente manejables, pero las técnicas para administrar el acoplamiento, las dependencias y las interfaces involucradas son mucho menos publicitadas, entendidas y disponibles que la simple técnica de mezcla. Lo mismo ocurre con las plantillas y la clase de política BTW.