c++ - negocios - Escalabilidad de las plantillas variad.

negocios escalables 2018

Question

Estoy trabajando en una infraestructura de software a gran escala en C ++ 11 que hace un uso extensivo de las plantillas variadas. Mi pregunta es la siguiente: ¿cuál es la escalabilidad de este enfoque? Primero, ¿existe un límite superior en la cantidad de argumentos que pueden tomar las plantillas variad? En segundo lugar, ¿el código es un problema importante con los compiladores de última generación cuando se usan muchos argumentos (y, por extensión, muchas combinaciones de estos argumentos que darían lugar a muchas implementaciones diferentes de los métodos de plantilla)?

Answer 1

Pensé que tendría que intentar averiguar si hay algún límite en el número de parámetros de plantilla para mi compilador en particular (g ++ 4.8.1 en Linux). Usé el siguiente caso de prueba:

template <int I>
struct this_is_a_ridiculously_long_struct_name_youd_never_use_in_real_life {};

template <int Depth, typename... T>
struct A
{
    using e = this_is_a_ridiculously_long_struct_name_youd_never_use_in_real_life<Depth>;

    A() {};

    A<Depth - 1, e, e, e, e, e, e, e, e, e, e, e, e, e, e, e, e, e, e, e, e, T...> a;
};

template <typename... T>
struct A<0, T...>
{
};

int main()
{
    A<899> a;
}

El límite de profundidad de recursión de la plantilla es de 900 en g ++, por lo tanto, el parámetro 899 que ve. El nombre de estructura ridículamente largo se usa para ver si podría generar algún símbolo que fuera demasiado grande para que lo manejara el enlazador. Más sobre esto en un segundo.

En caso de que no pueda ver lo que sucede en el caso de prueba, básicamente cada creación de instancias de A crea una variable miembro que agrega 20 parámetros de plantilla adicionales. La especialización parcial se utiliza para detener la recursión. Al final, A<0, ...> tiene un lugar en la región de 18000 parámetros de plantilla.

Lo que encontré fue que g ++ manejó esto muy bien. Tomó bastante tiempo pensarlo, y usé bastante memoria, pero no pude hacer que fallara simplemente aumentando el número de parámetros de la plantilla. Clang 3.1 también manejó esto sin ningún problema una vez que la profundidad de recursión de la plantilla se ajustó lo suficiente (es decir, 900).

Además, aunque los nombres de símbolos destrozados se vuelven enormes, no pude romper ni nm ni ld usándolos. (Vale la pena señalar que el esquema de gestión de Linux / Itanium utiliza la sustitución para que los parámetros repetidos de la plantilla del mismo tipo no repitan el nombre completo del tipo, sino que estén marcados como S0 , S1 , etc.). aumenta cualquier límite en la longitud del símbolo ELF, pero quizás alguien más sepa si existe tal límite.

En conclusión, entonces, para g ++ y clang en Linux al menos, no parece haber ningún límite práctico en el número de parámetros de la plantilla .

En cuanto a la segunda parte de su pregunta, con respecto al aumento de código, es muy difícil de decir, particularmente una vez que se involucra la optimización del compilador. Es fácil hacer una recursión con varias plantillas, pero también es fácil para el compilador deshacerse de los tipos intermedios. Solo puedo sugerir que lo prueben y vean.