Tengo curiosidad: ¿se usa mucho la programación genérica (GP) en la industria?
Depende mucho del contexto del equipo y del proyecto.
Por ejemplo, en los videojuegos, a menudo el código es el "más simple" posible (e incluso a veces demasiado simple) pero en grandes arquitecturas. Esto se debe a que los desarrolladores de juegos tienen muchos problemas que solucionar y no quieren molestarse con la meta programación (que es un lenguaje separado muy abstracto y difícil de entender dentro de C ++).
Al mismo tiempo, el uso básico de plantillas es común incluso en esas tiendas y puede ver algunas optimizaciones basadas en plantillas en algunas funciones muy específicas de algunos motores.
Pero en el desarrollo del juego, la mayoría de las personas simplemente evitarán cualquier metaprogramación.
Ahora, en el otro extremo, algunas aplicaciones de procesamiento realmente complejas o pesadas, que no son comunes, requieren algún tipo de metaprogramación pesada debido a los requisitos de rendimiento y flexibilidad (en tiempo de compilación) que no son comunes. Estoy trabajando en uno ahora mismo.
No es común, pero existe y algunos dominios de nicho (en algunos contextos incrustados de números o científicos) requieren que las personas sepan mucho sobre metaprogramación o deseen aprender.
En el medio, la mayoría de las personas usarán la metaprogramación como "cliente", no como "diseñador". La mayoría de los códigos de metaprogramación están agrupados en bibliotecas porque las bibliotecas son herramientas para el código y ¿qué es mejor que una biblioteca que pueda adaptarse a los tipos personalizados con los que ha estado trabajando hasta ahora?
Boost (http://boost.org) es un conjunto de bibliotecas, algunas de magia negra de metaprogramación pesada, y se utilizan en muchas tiendas de C ++ como "STL ++", una extensión de STL (y lo es). No todas las tiendas lo usan por varias razones, como la compatibilidad del compilador (algunas bibliotecas de impulso pueden hacer que su compilador pida perdón por cada vez que hirió sus sentimientos ...) y más a menudo porque a algunos desarrolladores no les gusta no poder entender cómo funciona una herramienta en su interior (intente comprender Boost.Spirit ...)
Independientemente de las empresas para las que trabaje, algunas utilizarán este paradigma, otras lo harán menos o nada o incluso las prohibirán.
No hay consenso porque nadie tiene las mismas necesidades, contexto o equipo.
Pero aún así, obviamente, se usa. Tal vez pregunte quién usa boost en su lista de correo para tener más ejemplos del mundo real.