¿Por qué no es bueno usar herencia recursiva para implementaciones std :: tuple?

Una implementación no recursiva tiene un mejor rendimiento en tiempo de compilación. Lo crea o no, en una biblioteca muy utilizada como std::tuple, cómo se implementa puede afectar (para bien o para mal) los tiempos de compilación que ve el cliente. Las implementaciones recursivas tienden a producir tiempos de compilación que son lineales en la profundidad de la recursividad (o pueden ser incluso peores).

Esto impacta más que solo la creación de instancias de la tupla en sí. std::get<I>(tuple) por ejemplo, tomará una cantidad lineal de tiempo de compilación para una implementación y una cantidad constante de tiempo de compilación para otra implementación. Este impacto puede deteriorarse rápidamente (o no) cuando se trata de tuplas de tuplas. Es decir, la implementación recursiva podría dar como resultado un tiempo de compilación O(N^2) mientras que la implementación no recursiva sigue siendo O(1).

Fwiw, la implementación de libc++ dispone los objetos en el orden especificado por el cliente, pero optimiza el espacio libre para los componentes vacíos utilizando la función de optimización de clase base vacía del compilador.

No recuerdo la charla GoingNative 2012 de Andrei Alexandrescu exactamente, pero habló sobre este punto, y uno de los puntos que mencionó fue el diseño de la memoria. si tengo un std::tuple<int, short, char, char>, quedará en la memoria como char, short, int y este diseño tomará (en mi sistema) 4 bytes más que si estuvieran dispuestos como int, short, char. R. Martinho Fernández me ha recordado que el el albergue mejor calificado Lo que hay que hacer sería ordenar estos en la memoria en un orden que minimice el relleno, que no es ni el orden dado ni orden inverso. (La herencia ingenua hace el orden inverso).

Si escribo std::tuple<int, char, short, char>, una tupla que funciona por herencia ingenua pondría estos en el orden char, short, int en memoria, usando 3 bytes de relleno, cuando óptimo tiene cero bytes de relleno. (Cualquiera int, short, char, char or char, char, short, int).

Suponiendo que tenga razón en que se trata de relleno, entonces R. Martinho Fernandes dicho "[mi argumento] no excluye el uso de la herencia recursiva para la implementación real en el orden óptimo", por eso especifico que ingenuo la herencia es mala.

(El orden en la memoria no no Significa que get<0> dará un objeto diferente, y R. Martinho Fernandes señala correctamente que el pedido debe ser invisible para el usuario. Sin embargo, estos fueron los puntos que me recordaron del evento GoingNative).

El video esta en http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Variadic-Templates-are-Funadic y las diapositivas están en http://ecn.channel9.msdn.com/events/GoingNative12/GN12VariadicTemplatesAreFunadic.pdf.

Una razón para no usar una cadena de clases base es que no hay una cadena de constructores involucrados: los argumentos se reenvían directamente al subobjeto apropiado. Además, parece que una implementación no recursiva ejerce mucha menos presión sobre el compilador y crea muchos menos símbolos [internos]. Sin mencionar que en realidad es más fácil no a una cadena de clases base.