c++ - sort - ¿El uso de std:: array<T, N> conduce a la inflamación del código?

sort vector c++

Question

Esta pregunta ya tiene una respuesta aquí:

• Plantillas C ++: autoconvicto contra código bloat 7 respuestas

He visto en algunos lugares la recomendación de usar std::array sobre arreglos tipo C en C ++, afirmando que es una alternativa mejor y más segura sin gastos generales. Ver:

La matriz de contenedor estándar no tiene [...] gastos generales de espacio más allá de lo que necesita para contener sus elementos, [...]. En otras palabras, es muy parecido a una matriz integrada sin problemas. ( Preguntas frecuentes sobre C ++ 11 )

Sin embargo, tal como lo entiendo, al ser un contenedor de plantilla habrá una sobrecarga en lo que respecta al tamaño del programa, ya que generará código para cada N diferente con el que se instancia una matriz.

Supongamos que mi programa usa std::array en varios lugares con varios enteros diferentes para N, ¿dará lugar a código inflado? ¿Es insignificante?

¿Debería preocuparme por esto para los parámetros de plantilla sin tipo en general?

Answer 1

Yo no me preocuparía por eso. Si nos fijamos en la interfaz de std::array<T, N> , es muy pequeña y la mayoría de las funciones de los miembros (que básicamente proporcionan wrappers para la manipulación de punteros) son lineamientos que cualquier compilador decente optimizará completamente. Libera los niveles de optimización del modo.

Además, no paga por lo que no usa, ya que las funciones de miembro no virtual no utilizadas ( std::array<T, N> no tiene funciones miembro virtual ) de las plantillas de clases tienen la garantía de no crear instancias. Cita pequeña estándar:

14.7.1 Ejemplificación implícita [temp.inst]

11 Una implementación no instanciará implícitamente una plantilla de función, una plantilla de variable, una plantilla de miembro, una función de miembro no virtual, una clase de miembro o un miembro de datos estáticos de una plantilla de clase que no requiera creación de instancias. [...]

También hay algunos operadores relacionales sobrecargados == y < que son semánticamente equivalentes a std::equal y std::lexicographical_compare . En la práctica, estos operadores también deberían implementarse en términos de estos algoritmos (quejarse a su proveedor si no lo hacen).

La única preocupación muy pequeña es una sobrecarga adicional en tiempo de compilación, pero no debe haber código cero y gastos generales de tiempo de ejecución.

Relacionado, pero no idéntico: el Informe técnico sobre el rendimiento de C ++ realizó una gran cantidad de pruebas de referencia detalladas sobre los tipos integrados ( int , double ) y encontró una sobrecarga cercana a cero para la tecnología del compilador de 2006. Podría repetir sus pruebas para verificar esto para std::array<T,N> vs. T[N]