C++ Sí muerde

Tal cual. Ha de ser por eso que por ahí circulan tantos mitos falsos de este magnífico lenguaje obra de una gran mejora que a principios de los ochenta hizo el joven Stroustrup sobre el ya mítico C pelao que nació a principios de los 70 como lenguaje para Unix que sí; estaba basado en el lenguaje B que a su vez fue engendrado a partir de BCPL (esto ya parece el Génesis).

Bueno; pues la idea de este artículo no es demostrar que C++ Muerde, sino qué hacer para que no nos muerda.

Eso sí, estaré escribiendo de C++ en el mundo de desarrollo Microsoft. Específicamente en Visual Studio. De hecho, lo que me motivó a escribir esto, es que por ahí a un amigo le dijeron que la aplicaciones C++ hechas con VS nunca podían ser tan rápidas cómo las de C++ nativo. Cosa que aunque es parcialmente cierta, tiene más de falsedad que de verdad.

 

Verán, con Visual Studio y C++ podemos crear dos tipos de aplicaciones esencialmente.

1. Nativas: Que corren en los PCs sin necesidad de instalar nada adicional. Se usa la versión de C++ definida por la ISO/IEC. Así que estas sí corren con toda la velocidad posible.

2. C++/CLI (Administrado): Como bien atina a llamarlas el señor Ivor Horton en su libro Beginning Visual C++, estas son aplicaciones que aunque están creadas con el lenguaje C++, requieren del Framework.net para funcionar (Así que en este caso C++ es uno de los cerca de 20 lenguajes de programación que se pueden trabajar con .NET). Obviamente, se ofrecen funcionalidades más evolucionadas y sencillas para desarrollar más rápida y eficientemente. Pero estas abstracciones tienen un costo a la hora de ejecución que aunque pocas veces llegan a notarse, bajo ciertas circunstancias son cruciales. Recibe el nombre de administrado, porque el Framework.NET se encarga de la seguridad del código y de la optimización del manejo de memoria y otros aspectos que nativamente tenemos que hacer con nuestras propias líneas de código.

No es más que una de las tantas paradojas que tenemos en nuestra carrera. A mayor abstracción, menor velocidad.

Piense por ejemplo en ir de un punto A a un punto B. Puede escoger ir en un auto de carreras de esos que para ser rápidos les han quitado la silla del copiloto y acompañantes, el tablero, y todas esas comodidades. O también puede escoger ir en una casa rodante con jacuzzi, televisión satelital y Kinect. En este caso, tiene todas las comodidades; pero la velocidad no es la misma…

Ciertamente es un poco exagerado el ejemplo, pues la diferencia en velocidades no es tan grande a decir verdad; solo que a veces sí se requiere.

Otra cosa más de notar sería por ejemplo que al ser más básico, C++ nativo tiene menos restricciones y permite construir cualquier tipo de software, aunque esto signifique comenzar de ceros sin aprovechar piezas prefabricadas como las que componen .NET.

De hecho sobre el propio C++ nativo se han tratado de crear abstracciones propias para poderle programar más fácil. Es así como surgió la librería estándar de C++ que es la que se usa en la mayoría de programas creados con este lenguaje. Microsoft creó MFC (Microsoft Foundation Classes) para abstraer el acceso a los recursos del sistema operativo e intervenir la interfaz gráfica de Windows. Como es de suponerse, programar con estas librerías, es más sencillo, pero al ejecutar la velocidad no es la misma. Igual se puede acceder al API de Windows sin necesidad de MFC para ir más rápido (eso si se considera un Programmer Hero! Pues crear una aplicación con unas cuantas ventanas usando solo C++ nativo puede tomarle meses mientras con C++ administrado o a través de MFC, ese tiempo se reduce a un par de semanas). Además, sí puede decirse por ejemplo que un programa creado con MFC es más rápido (aunque no se note) que uno creado con C++ administrado.

 

Para cerrar hasta aquí podría decir entonces, que en general las diferencias en tiempos de ejecución no son tan abismales como sí las de desarrollo. Pero sé de aplicaciones que estando en .NET han tenido que devolverse por cuestiones de performance. Por ejemplo, el cliente de Evernote para Windows, una aplicación con una interfaz gráfica muy enriquecida y específica que almacena notas de todo tipo y hace búsquedas complejas sobre ellas, estaba hecho en WPF; se devolvió a C++ (programado con Visual Studio) para lograr un mayor rendimiento.

Sin embargo Evernote debe en gran parte su éxito a lo fácil que les fue crear la aplicación en sus primeras versiones gracias a las grandes abstracciones brindadas por WPF y al poder de .NET. Luego ya con todo lo ganado en esas versiones, decidieron incrementar el número de funcionalidades; cosa que requería más trabajo de ingeniería, pero se podían dar ese lujo dado que ya tenían algo en producción que les daba revenue.

No quiero decir que deben pasar todas sus apps a C++. Solo que cuando lo necesitemos allí estará.

Para terminar esta entrega aquí les dejo este gráfico que me ayudo recopilar @raptorttk del libro de Horton, para que vean las opciones de cuando programar C++ en Visual Studio se trata: