No uses goto, que yo lo usaré

Estaba yo esta mañana más aburrido que una ostra (y eso que tengo curro, pero a veces uno no es capaz de tirar una sola línea de código) y me dio por abrir el .NET Reflector, ahora de Red Gate.


A veces suele darme por mirar en las tripas del .NET, sólo por mera curiosidad y completamente al azar, y a veces también me desespero al ver cómo una llamada en código .NET termina, tras varios niveles de anidación completamente vacíos, en una llamada a una función nativa de Win32. Conociendo el fabuloso desempeño del jitter de .NET con el código muerto (recomiendo leer toda la serie desde la primera entrada hasta la última), me asombra que a veces la máquina virtual llegue a funcionar a una velocidad aceptable (que lo hace).


Pero esta mañana me he llevado una sorpresa. Abriendo el árbol de System.IO me encuentro con una clase llamada «Pipes». Hasta donde yo sabía, el .NET Framework no soportaba el concepto de pipe nativo, pero parece ser que en la versión 3.5 ha sido añadido.


Como me ha llamado la curiosidad, me he metido dentro del código y en el primer sitio que he mirado, el método Connect() de NamepClientPipeStream, los ojos han empezado a llorarme. Al lector también pueden llenársele de lágrimas si mira la imagen adjunta. Sí, efectivamente, hay tres equiquetas de tipo «label» y nada más y nada menos que cuatro gotos diferentes…


image


No me vale que me digáis que es cosa del optimizador: el optimizador de C# no es capaz de transformar el código de esa forma (cosa que el de C++ no sólo es capaz de eso, sino de más).


Pero la cosa no acaba ahí, sino que el método WriteFileNative de la clase PipeStream es todavía, si cabe, más curioso:


image


Básicamente se está saltando toda la seguridad y está escribiendo directamente desde un puntero de C# bloqueado con la sentencia fixed que se correspondería con un pin_ptr de C++/CLI (Hay que decir, que las clases que llaman a este método comprueban muchas cosas antes de llamarlo)…


Personalmente opino que el uso de todos esos gotos está más que justificado, pero vamos a dejar al lector que piense por qué.

Guía de diseño para la Ribbon de Office

Tras el patinazo de ayer (resulta que todos los mensajes sobre la duración de la batería eran del mismo tipo -efectivamente, el artículo está borrado), hoy vamos a hablar de algo más interesante. A través del blog del equipo de Visual C++, descubro que los chicos de Microsoft han publicado en la MSDN una guía de diseño para la Ribbon.


Aun tratándose de documentación preliminar, y tras echarle un rápido vistazo, veo que la guía documenta en profundidad los conceptos sobre el diseño de una Ribbon, aclarándonos, entre otras cosas, cómo se llama cada parte de la misma. Ciertamente se trata de un documento muy interesante y completo. La lástima es que esté en inglés, pero como incorpora muchas imágenes casi no es necesaria su lectura para entender qué nos está contando.


El documento está destinado a los desarrolladores y diseñadores de C++ y MFC que estén utilizando el nuevo control Ribbon que incorpora el Feature Pack añadido al Service Pack 1 de Visual Studio 2008, pero creo que también puede ser de utilidad para aquellos que construyan Ribbons en otros lenguajes/tecnologías…


 Finalmente, el artículo se puede leer desde aquí: