Acerca de...
El equipo
Encuestas
Política de privacidad
WinTablets

Encuesta

¿Cual crees que triunfará?

Ver Resultados

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Archivos

03
Sep 2015
C++DesarrolloMetroModern UIPrácticosrfogdevtrucosWorkarounds

¿No se inspeccionan bien las variables en el depurador de Visual Studio 2015? Solución

Resulta que el otro día el que viste y calza se cansó de que el depurador de Visual Studio 2015 no funcionara bien, que tuviera que adivinar el contenido de cualquier tipo compuesto, por lo que se pasó a la versión 2013 después de enviar un informe de error a Microsoft.

Pues resulta que no, que Visual Studio 2015 funciona bien. Más o menos.

Todo vino cuando comenzaron las cosas difíciles de verdad en el proyecto que estoy realizando ahora mismo, en el que necesitaba mirar con detalle el contenido de variables y objetos complejos. Léase vectores, mapas, estructuras con varios datos miembro y demás. Incluso un simple string estándar no se veía bien.

Como la captura que os muestro.

stldebuggercapture

Digamos que el inspector de código es incapaz de mostrar nada a derechas. O a izquierdas, ya puestos. Mientras no necesité ver elementos complejos, me iba defendiendo con la salida por OutputDebugString() del sistema, y por la ventana de código inmediato, que me permitía ver, por ejemplo, el contenido de un std::wstring llamado cadena mediante el tecleo de “cadena.c_str()”.

(Sí, amigos, Visual Studio también permite trastear con los datos en tiempo de ejecución de forma bastante sencilla, igual que C#, aunque algunas veces, sobre todo si es una expresión compleja, no puede con ella).

Si habéis leído por ahí, Microsoft está implementando una nueva familia de compiladores que, entre otras cosas, permite generar código nativo .NET. Sí, amigos, tras más de diez años, por fin se han dado cuenta de que .NET, si no es nativo, no vale para mucho.

El API de las aplicaciones modernas, o Metro, o como os dé la gana llamarlas, es nativo. No es .NET aunque si quieres puedes usar C# para hacer tu aplicación, que terminará llamando a una primitivas escritas en C++/CX y C++ puro y duro, como tiene que ser.

De hecho puedes crear aplicaciones modernas desde C++/CX que usan el mismo API que el .NET desde C#. Eso sí, apenas hay cosas documentadas. También es cierto que la diferencia de rendimiento puede ser asombrosa.

Pues bien, el siguiente paso son las Aplicaciones Universales (de Windows 10) escritas en C# y VB.NET que terminan siendo compiladas a código nativo, usando las mismas API que si la hicieras en C++/CX. En este caso, .NET Framework (al menos la parte en relación a lo que hablamos aquí), no es más que una biblioteca clásica y no todo un Framework con su máquina virtual, su jitter y todas las demás zarandajas del desarrollo manejado.

Podríamos decir que, tras más de diez años, Microsoft ha visto la luz. :-)

Pues bien, todo eso requiere (o se supone que requiere, no he entrado en detalles), un nuevo compilador, un nuevo depurador y nuevas herramientas.

Y eso quiere decir que Visual Studio 2015 viene con dos sabores, el clásico y el modelno. En general todo el tema es transparente para el desarrollador. En modo Debug más o menos se usan las herramientas clásicas, en modo Release las modernas, que generan mejor código.

¿Y qué pasa con C++? Pues que también se sube a la ola de la modelnidad. Realmente no me he preocupado qué cambios han hecho en el compilador ni a qué nivel. Lo que sí me ha preocupado es que, arrastrar un proyecto de Visual Studio 2013 a 2015 puede ser un poco traumático (y si no que se lo pregunten a Peni y sus lambda).

O bastante traumático si deja de funcionarte el depurador.

Y eso es lo que me pasó.

¿Hay solución?

Sí, y bien sencilla que es.

Cuando pasas de la edición 2013 a 2015, si no limpias el código ni reasignas los proyectos, aunque subas la versión del compilador, tienes que activar las dos casillas de la captura, porque si no lo haces el debugger no funciona.

vsoptions

Pero si lo haces, resulta que entonces las variables y objetos no se ven bien.

¿La solución? Limpiar completamente la solución, a mano, no vale con el menú contextual (es decir, borrar todas las carpetas temporales y demás), y luego hacer un “Retarget Solution” (No sé cómo se dice en español, mi versión está en inglés).

Después de eso, mano de santo, oye.

Y encima ganas el medidor de rendimiento y de uso de memoria y CPU.

Actualización 04/09/2015

Bueno, tras estar un par de días funcionando, la cosa ha dejado de funcionar otra vez. En este caso se trata de que el depurador no se detiene en los breakpoints. Esto es un bug que trajo durante un tiempo Visual Studio 2013 y que parchearon en su momento. Pero parece ser que ha vuelto.

Al final, y a la espera de que la gente de Microsoft se pronuncie (hay un bug abierto sobre esto), solo me quedan dos posibles soluciones:

  1. Marcar la casilla de habilitar la compatibilidad con código manejado antiguo, y entonces ya funciona todo más o menos bien. El problema es que la inspección de variables, dependiendo de su tipo, a veces no muestra nada coherente, o muestra unas cosas y otras no. Por ejemplo, los vectores no muestran nada, y algunos objetos de boost muestran tonterías en lugar de los valores correctos. Imaginaos depurar sin saber si lo que se ve mal es culpa tuya o del debugger. Pues eso.
  2. Volver a Visual Studio 2013. Que es lo que he hecho. Como me apoyo en Visual Assist de Whole Tomato, las características nuevas de la versión 2015 ya las tengo con este asistente.

Pues nada, permaneced atentos porque iré actualizando esta entrada con las novedades que haya (si las hay).

Por RFOG | 3 Comentarios | Enlaza esta entrada
contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)