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

Question

Uso plantillas mixins en C++ mucho, 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 C++ y no me veo moviéndome 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 resumen si no sabe cuáles son, y expone el caso con tanta claridad en términos de reutilización y rendimiento.

Answer 1

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

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

class Base2 { public: Base2(Special const&, Special const&); }; 

Y ahora, mi súper mixin:

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

¿Notas el problema aquí? ¿Cómo diablos se supone que debo pasar los argumentos al constructor de la clase base? ¿Qué tipo de constructor debería indicar Mixin?

Es un problema difícil, y no se ha resuelto hasta que C++ 11 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 controles dobles son bienvenidos

Así ahora realmente podemos utilizar mixins ... y sólo hay que cambiar los hábitos de la gente :)

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

Uno de los problemas con mixins (que el artículo defectuoso que referencia omitir felizmente) es el aislamiento de dependencia que 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 ciclos de CPU ... y esos son generalmente más baratos.

Answer 2

Las plantillas requieren que la implementación sea visible en la unidad de traducción, no solo en el tiempo del enlace (direcciones C++ 11 que si solo usa un puntero o referencia a instancias). Este es un problema importante para el código de bajo nivel en los entornos empresariales: los cambios en la implementación desencadenarán (podrían o no ser automáticamente) números masivos de bibliotecas y clientes para recompilar, en lugar de simplemente volver a vincular.

Además, cada instanciación de plantilla crea un tipo diferenciado, lo que significa que las funciones destinadas a funcionar en cualquiera de las instancias de plantilla deben poder aceptarlas, ya sea que se ven forzadas a ser modeladas o necesitan una forma de transferencia a polimorfismo en tiempo de ejecución (que a menudo es bastante fácil de hacer: solo necesita una clase base abstracta que exprese el conjunto de operaciones admitidas, y alguna función "obtener un descriptor de acceso" que devuelve un objeto derivado con un puntero a la instanciación de la plantilla y entradas relacionadas en el tabla de despacho 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 fácilmente disponibles que la técnica de mixin simple. Lo mismo es cierto para las plantillas y la clase de política BTW.