¿C++ ó C#?

Recuerdo la primera vez que oí hablar de .NET y C#. Alguien en la oficina lo estaba usando en casa para no sé qué juego de fútbol y lo contaba con entusiasmo. A mí me sonaba por aquel entonces a una especie de lenguaje de segunda división pensado para las masas, fácil de usar por cualquiera que quisiera desarrollar rápidamente un portal web o aplicaciones de gestión y manejo de bases de datos. Me imaginaba al panadero de mi barrio con el Visual Studio. Al igual que Java muchos años antes, .NET introducía algunos conceptos que mi mente cuadriculada de C++ no podía tolerar: “¿Recolector de basura?” “¿Que no puedo decidir dónde ni cuándo destruir los objetos que yo mismo he creado? ¿Cómo se atreve?” y la puntilla: “Y es 20 veces más lento, definitivamente no vale para programas de verdad”. Qué atrevida es la ignorancia.

Un par de años más tarde tuve la oportunidad de trabajar con C# en un proyecto. Inicialmente sólo éramos dos programadores que sumábamos más de 25 años de experiencia en C++ y cero en C#. Aunque a mí no me apetecía cambiar, el tipo de proyecto, su corto tiempo de desarrollo y los pocos recursos disponibles aconsejaban su uso. En dos meses debíamos tener listo un prototipo.

Al principio lo hacíamos todo en C++ disfrazado de C# (no sabíamos hacer otra cosa al fin y al cabo), pero poco a poco nos fuimos enganchando y entendiendo el verdadero potencial de la herramienta. Era un lenguaje formal, elegante, muy estricto en cuanto a las formas, de modo que era prácticamente imposible retorcerlo para usarlo de una manera digamos creativa. Un lenguaje diseñado, entre otras cosas, para cubrir las necesidades reales de un programador y hacerle la vida más sencilla.

Si hay algo que multiplica por 100 el valor de cualquier lenguaje .NET es el Framework Class Library (FCL), una vastísima colección de clases destinada a ser la base sobre la que construir componentes, servicios, aplicaciones y en definitiva cualquier solución software. Se acabó el tener que recurrir a la búsqueda de librerías de terceros, a veces caras, difíciles de mantener, de dudosa calidad, indocumentadas o en el peor de los casos incompatibles entre sí. Con la librería de clases tenemos prácticamente todo lo que nos podamos imaginar a la distancia de unos pocos clicks, con el añadido de disponer de un API consistente tanto en funcionalidad como en estilo (el 90% de las veces).

Otra de las cosas que se hace notar es que es un lenguaje vivo en constante evolución. En cada nueva release podemos encontrar características de lo más variadas que lo van situando poco a poco en la categoría de lenguaje ‘todoterreno’. La única pega, por el momento, es que está confinado a la plataforma Windows, aunque paralelamente se está desarrollando Mono, un proyecto Open Source impulsado por Novell con Miguel de Icaza a la cabeza, con el objetivo de hacer posible el desarrollo de aplicaciones .NET en Linux, BSD, UNIX, Mac OS X, Solaris y el mismo Windows.

En definitiva, cada día que pasaba descubríamos un par de cosas nuevas que nos dejaban asombrados. Reconozco que de cuando en cuando nuestro pasado nos cegaba: “¡Maldita sea, se les ha olvidado meter ‘x’ en C#!”. No, no se les había olvidado, simplemente se hacía de otra manera, más elegante, mejor. Una cosa importante que hay que tener en cuenta para evitar frustraciones futuras es que C# no es una forma de C++, ni siquiera es una evolución del mismo. Son dos lenguajes diferentes de la misma familia que comparten una sintaxis muy parecida. Por parecerse a algo se parece a Java, lenguaje del cual ha heredado las cosas buenas y desechado las malas.

Después de un par de meses trabajando en C# tomé la decisión de reescribir el HD con esta nueva y perfecta herramienta. Tenía un montón de código pero se limitaba a un framework sobre el que basar el core de la aplicación. Para mi sorpresa, el FCL tenía todo lo que durante meses había estado escribiendo: listas enlazadas, pilas, diccionarios, gestión de memoria, gestión de ficheros etc, y solo me llevó una semana tener el nuevo motor funcionando. Básicamente más que reescribir código fue tirar el antiguo y reemplazarlo con algo que ya estaba hecho y probado, con mucha pena en el alma eso sí.

El único apartado en el que tenía dudas era en la parte de DSP. Se me ocurrió escribirlo primero en C# para tener algo funcional que después podría pasar a C ó C++ . La primera implementación era terriblemente lenta, pero entonces descubrí el modo unsafe, dentro del cual es posible escribir código libre de comprobaciones extras por parte del compilador, haciéndolo muy eficiente y peligroso a la vez. Básicamente tienes acceso directo a la memoria a través de punteros estilo C/C++, por lo que si no se manejan con cuidado pueden causar los mismos estropicios de antaño, como sobrescribir variables, provocar desbordamientos de pila, pisar zonas de memoria etc. Si esto ocurre y tienes mucha suerte tu desliz provocará un crash inmediato, en caso contrario prepárate para un dolor de cabeza seguro.

Por el momento no he tenido la necesidad de escribir nada en C++. Haciendo un poco de profiling  en un ordenador de gama media he llegado a mezclar simultáneamente cerca de 150 pistas de audio 16 bits estéreo a 44.100 hz,  todas con envolventes de pitch y volumen, lo cual es mucho más de lo necesario en cualquier aplicación práctica.

En definitiva, y hasta que no se me demuestre lo contrario, he desterrado el C++ de mis herramientas del trabajo, algo que a algunos les puede parecer un sacrilegio. Quizás algún día necesite hacer alguna rutina que precise de millones de cálculos y deba ser llamada millones de veces por segundo. Bueno, pues ese día usaré C ó C++, al igual que antaño se usaba el ensamblador para estos casos.

~ por trapazza en Mayo 4, 2009.