Novedades para C++ y C++/CLI del nuevo Orcas

Antes de ayer el Visual C++ Team publicó en su blog una entrada contándonos las novedades que el futuro Visual Studio va a traernos a los desarrolladores de C++ nativos y de C++/CLI. Mi intención era poner esto ayer, pero por falta de tiempo no pudo ser. Y justo en el día de ayer algunos blogs en inglés se hacen eco de dichas novedades.

Menuda expectación, je je.

Lo que se dice revolucionarias, revolucionarias, no hay ninguna mejora, aunque sí bastante interesantes todas ellas. La única que podría serlo es la STLCLR, pero como ya se esperaba su inclusión no llama en exceso la atención.

STLCLR

O por otro nombre STL.NET. Toda una gozada, oiga. Hasta ahora, el programador que hubiera querido utilizar la STL nativa con estructuras de datos .NET se habría encontrado con un serio problema tanto de rendimiento como de implementación: dicho uso requiere que los elementos .NET a tratar fueran envueltos en objetos proxy y utilizados de forma cuidadosa para evitar extraños efectos laterales y una caída drástica de la funcionalidad. Por lo que al final se terminaban utilizando los genéricos, que no son lo mismo.

Pero como dice el anuncio, «el frotar se va a acabar». La STLCLR implementa la STL por completo de forma manejada y para tipos .NET. O sea, que a partir de Orcas vamos a disponer de nuestra querida STL completamente integrada dentro del .NET. Que no es poco ni moco de pavo. Esperemos que lo hayan hecho bien y que no sea otra pesadilla en cuanto a bugs.

Elegir qué versión de .NET utilizar

A partir de Orcas podremos elegir sobre qué .NET generar, desde la versión 2.0 en adelante. Como la 2.0 es una castaña en cuanto a una serie «seria» de bugs relacionados con el C++/CLI (léase problemas con los constructores estáticos, problemas con variables sin inicializar, y un largo etcétera), la 3.0 no está soportada (es decir, usa lo mismo que la 2.0), sólo nos queda la 3.5 que, según he podido comprobar, soluciona unos cuantos de los bugs citados.

Biblioteca «Marshaling»

Junto a las técnicas de «ijt» (es decir, incluye el fichero cabecera y haz la llamada al código nativo) y las de interop típicas del .NET, vamos a disponer de una nueva forma de pasar y convertir variables nativas y manejadas mediante una nueva biblioteca con estructura similar a la de las plantillas. Otra nueva gozada.

Asmmeta y /MP

Quien haya programado con C++/CLI, y más aún, con código nativo y manejado simultáneamente habrá descubierto cómo los tiempos de compilación se incrementan hasta niveles insospechados, y cómo el uso de cabeceras precompiladas apenas solucionan el tema. Habrá visto que un pequeño cambio en un fichero fuente implica la recompilación del proyecto completo sin mucha lógica aparente.

Pues dos nuevas opciones vienen a intentar mejorar dichos temas. La primera consiste en integrar el programa asmmeta.exe dentro del IDE para que minimice las dependencias y sólo se compile el código estrictamente necesario.

La segunda es la nueva opción /MP del compilador, que distribuye la compilación en entornos multiprocesador/multinúcleo de forma más efectiva. Hasta ahora, en los entornos multiprocesador, y siempre que la solución tuviera más de un proyecto, la compilación se realizaba de forma paralela respecto a los proyectos. Con esta nueva opción (que impide otras opciones como las cabeceras precompiladas) la compilación se realiza por fichero/núcleo, agilizando, según la documentación, en un 40% los tiempos de compilación para un QuadCore frente a un procesador normal.

Diálogos comunes

Como era de esperar, se actualizará toda la parafernalia de los nuevos controles comunes del Vista, la nueva forma de entender los cuadros de diálogo y los nuevos controles que el Vista trae incorporados.

En concreto se amplían las clases MFC para dar cabida a todo esto, el editor de recursos se mejora y se actualiza (hoy otro amigo del Visual C++ Team ha puesto una nueva entrada sobre ello aquí) para poder crear todos estos nuevos controles y en general se hace lo que debe hacerse. Aquí no hay ninguna ventaja ni ninguna mejora que no sean las obvias.

Otros

Entre las nuevas cosas con menor relevancia, está el soporte de plantillas amigas, es decir, la posibilidad que otros compiladores estándar tienen y el Visual C++ no.

También se va a realizar un mejor control de versionado de las bibliotecas de tiempo de ejecución (runtimes) para que aplicaciones realizadas con diferentes .NET y diferentes versiones del Visual Studio puedan funcionar lado a lado sin problemas.

Se actualizan temas relativos al UAC para que las aplicaciones entiendan y sepan moverse con esta nueva característica. Lo más importante es que a la hora de crear un nuevo ejecutable podremos decirle cuáles son sus privilegios y sus necesidades.

En el otro lado, retiran el soporte para ATL, ISAPI y alguna que otra tecnología.

Lo que falta

Y no es poco. Quizás lo añadan, pero de momento no han dicho nada. Hace tiempo Microsoft se comprometió a soportar con MFC todo lo que los nuevos .NET soportaran pero de momento no hay nada sobre ello. Y por no haber no está ni la página WEB con el compromiso, aunque sí otras que hacen referencia a la misma:

• La página original: http://msdn.microsoft.com/visualc/whidbey/mfc2005/default.aspx
• Una de Nish que hace relación a la misma: http://blog.voidnish.com/?p=86
• Otra más: http://www.miraesoft.com/karel/2005/05/25/the-future-of-mfc/

Mi pregunta que dejo en el aire es: ¿Ha vuelto a mentir Microsoft de nuevo y está matando a la chita callando las MFC?