Microsoft ya está planeando y compilando la siguiente versión de Visual Studio, que ellos han llamado temporalmente vNext o, recientemente, 2011, para indicarnos que se trata de la siguiente versión. No hay nada definitivo, ni fecha de salida ni qué va a traer, pero haciendo un poco de gurú, y teniendo en cuenta el ciclo bianual de salida, posiblemente tengamos algo el año que viene por estas fechas o un poco antes. Y no, no estoy haciendo uso de ninguna información privilegiada, que últimamente a los MVP nos dicen lo mismo que a los demás.
No obstante ya se empiezan a publicar algunas novedades sobre lo que va a traer. No son definitivas y quizás al final no las incluyan, pero tienen cosas bastante interesantes. Pese a referiros a los enlaces originales, os cuento yo aquí algunas cosillas. Iremos cronológicamente conforme han ido saliendo, ya que el interés también va en ese sentido.
Según Sumit Kumar, van a potenciarlo hasta el nivel de C# y más allá. Vamos a tener color para más elementos semánticos, de hecho hablan de hasta veinte tokens a los que podremos aplicar diferentes colores. Es decir, podremos distinguir a simple vista si un nombre es una variable local o global, una macro, una plantilla, un parámetro, un espacio de nombre, una enumeración… cosa que no está nada mal.
También habilitan la selección de una misma referencia en todo el código fuente. Es decir, cuando pongamos el cursor sobre un símbolo, dicho símbolo se selecciona en todo el texto.
También traerá un analizador heurístico en los desplegables, que se abrirán automáticamente y nos mostrarán los tipos más comunes y más probables pese a que empecemos a teclearlos mal.
Y, para equipararse a otros lenguajes, se añaden los Code Snippets, que son bloques de código listos para insertar.
Ne da un poco de corte explicar lo de arriba, porque todo eso ya lo hace Visual Assist de Whole Tomato… pero bien está que lo traiga de forma nativa… si funciona. Recordemos que no es la primera vez que el IntelliSense falla por completo en un producto de Microsoft. Esperemos que esta vez acierten a la primera.
Otra cosa que nos cuenta Sumit, y que personalmente yo no le veo mucho sentido, es que el Explorador de Soluciones traerá una vista de clases. Es decir, cuando abramos un fichero en dicha ventana, tendremos acceso a todas las clases y todos los símbolos de forma automática.
Si queréis ver las capturas de pantalla de todo lo que he explicado, haced clic en el enlace de arriba y veréis todo eso en marcha.
Amit Mohindra nos explica otras novedades en torno al IDE. La más destacable es que ahora no existe asistente para actualizar la solución. Es decir, si abrimos una solución escrita con Visual Studio 2008 o superior, no nos pedirá actualizarla y podremos usarla aprovechando las mejoras del nuevo IDE, y todavía podremos seguir abriéndola con la versión anterior.
Aquí surge un problema potencial, y es el uso de los nuevos compiladores. Es decir, imaginad que no tenemos instalado Visual Studio 2008 en la máquina en la que abrimos la solución pero sí Visual Studio vNext… Pues bien, existirá la forma de utilizar el nuevo compilador. Este tema está todavía pendiente de estudio, por lo que no está claro cómo lo van a hacer.
Otra cosa interesante va a ser la creación de plantillas de proyectos. En versiones anteriores había que crear una serie de ficheros bastante complicados de entender. Ahora esto podrá hacerse mediante un asistente. Aquí y aquí se explican algunas cosas más sobre esto.
Siguiendo con la lista de novedades, y conforme se van publicando en los blogs de Microsoft, ahora nos toca hablar de una característica que yo considero muy pero que muy potente en relación a la ejecución de código en paralelo.
Recientemente Microsoft ha sacado una biblioteca que ha dado en llamar C++AMP, y de la que podemos leer por aquí. Ignoro si forma parte de algún estándar (lo siento, ando un poco desactualizadillo en estos temas), pero creo que sí, al menos en su especificación si no en la implementación. Las siglas se conocen como Accelerated Massive Parallelism, y tiene que ver con los procesadores de uso generl multinúcleo y los vectoriales SIMD (de los cuales forman parte los chips de las tarjetas de vídeo modernas).
Evidentemente esto no sirve para un programa de gestión de datos, pero sí para juegos y otras aplicaciones que necesiten un rendimiento alto y que realicen tareas que se puedan ejecutar en paralelo. Digamos que es la solución que Microsoft está implementando en el mundo nativo (C++) como solución a los problemas actuales de paralelismo, y personalmente no lo veo nada mal.
Pues bien, DanielMoth nos cuenta que en vNext tendremos una nueva palabra reservada llamada restrict y que nada tiene que ver con su equivalente de C99, que MS no implementa. Básicamente la idea es utilizar dicho término para indicar dónde se debe ejecutar un método, si en el procesador principal o en el SIMD (tarjeta de vídeo).
Es decir, si nosotros ponemos algo como
void myFunction(int a) restrict(cpu)
{
}
Le estamos diciendo al compilador que esta función deberá ser ejecutada por la CPU del sistema, mientras que si lo indicamos así:
void myFunction(int a) restrict(direct3d)
{
}
Estaremos indicando que eso se debe ejecutar en el procesador gráfico.
E incluso es posible algo como esto:
void myFunction(int a) restrict(direct3d, cpu) //o restrict(cpu, direct3d)
{
}
Que indica que se podrá o deberá ejecutar en ambos procesadores.
Lo chulo de esto es que se trata de una indicación transparente para el programador, y que debe ser la implementación la que se encargue de toda la martingala para que pueda ejecutarse en uno o en otro sitio.
También podremos sobrecargar el método, de forma que podríamos tener tres funciones idénticas pero con diferente restricción, de forma que sería el compilador y el motor de tiempo de ejecución el que decidiera qué y cómo ejecutar.
Toda una chulada.
De todos modos, esto está un poco en el aire, y todavía no tienen claro algunas partes de la implementación y cómo va a terminar funcionando, pero es una característica muy guapa. Ojalá implementen algo similar para los threads y la sincronización.
Otra cosa que sí han hecho es optimizar el PPL (otra librería de ejecución en paralelo, esta con algo más de solera), ganando en algunos casos hasta un 20% de mejoras en el rendimiento con sólo recompilar el código existente con la nueva implementación de PPL que traerá vNext. Aquí lo tenéis con más detalle.