Hemos leído: Adam Nathan: Windows Presentatio Foundation Unleashed

image La idea de adelantar casi un año la lectura de este libro respecto a mi plan ha sido la de hacer un programa utilizando WPF, pero al final ha sido peor el remedio que la enfermedad. O dicho de otro modo: pese a ser enormemente potente, pese a soportar temas, pese a contener ideas relativamente nuevas y bien implementadas… no lo voy a hacer con WPF. Simplemente es que no me gusta cómo ha sido expresada dicha potencia. Me han dicho que quizás si leyera el libro equivalente de Petzold lo vería de otro modo, pero de Petzold ya tuve bastante con el de Programación en Windows con C#, que contenía más errores que aciertos.

Sí, ya sé que los libros de Petzold sobre Win32 y C son una referencia de base, de hecho tengo tres ediciones de las cinco que hay, pero por eso mismo: la referencia son estos, no los nuevos. No creo que nadie pueda negarme que el de C# no tenga errores.

Sin embargo, el de Nathan es otra cosa, y pese a tener ya más de tres años, sigue siendo actual y no desmerece para nada. Me dicen que pasa lo mismo con el de Petzold, que quizás compre y lea.

Dividido en cinco partes, ninguna tiene desperdicio. En la primera se nos presenta XAML y lo que significa para WPF, así como los conceptos que hay detrás de todo esto. Lo más destacable es que, a partir de un fichero de marcas como es XAML (que no es más que una variación de XML), el sistema es capaz de construir el tipo de interfaces que es capaz de hacer. Aunque suene un poco como a magia, no lo es, ya que la construcción del fichero y los tags son complejos.

Otras cosas interesantes son las propiedades propagadas, en las que si tu modificas una de ellas, todos los hijos las modificarán de acuerdo al cambio, con lo que variar aspectos de la UI puede llegar a ser trivial en muchos casos. En los eventos ocurre parecido: si uno hace clic en un componente que no tiene dicho evento asignado, éste irá subiendo por el árbol hasta llegar a alguien que lo maneje. Si bien esto último puede sonar espectacular en .NET, en MFC y otros frameworks es el comportamiento habitual.

La segunda parte nos presenta los controles de que disponemos en WPF. Pese a toda su enorme potencia a veces resultan escasos, porque básicamente son una serie de contenedores. A los programadores de GTK o de QT les deben sonar los componentes de layouts y fluentes en el sentido de que reordenan los hijos de forma automática. Aparte de los botones, los cuadros de lista, los combos y los labels, pocos más hay. También nos cuenta cómo juntar todo esto en un programa, y crea una especie de clon de las ventanas de Visual Studio, y digo "especie de" porque realmente el soporte de docking está como ausente, pero aceptaremos pulpo pese a no haber hablado de arrastrar y soltar (que me temo WPF no soporta directamente).

En la tercera nos explica cómo trabajar con recursos, enlace a datos y el soporte para estilos, plantillas (de estilos), pieles (skins) y temas. Aquí me he llevado otro pequeño desengaño, ya que pese a la potencia de todo esto, resulta sensiblemente difícil añadir o cambiar el aspecto de una aplicación. Para hacerlo es necesario al menos saber XAML, y presenta un potencial y enorme agujero de seguridad ya que dicho XAML puede contener código arbitrario…

La penúltima parte cubre la multimedia: cómo hacer gráficos 2D y 3D, animaciones, vídeo y audio. Pese al soporte ampliado, la verdad es que no hay mucha mejora respecto a otras tecnologías.

La quinta y última parte sí que es interesante, por lo menos para mi: Interoperabilidad con Win32, C++/CLI, COM, ActiveX y Windows Forms. De todos modos, nada nuevo bajo el sol, y para ver interoperabilidad entre C++/CLI y WPF y/o Windows Forms de verdad, el libro de Sivakumar. También vemos cómo crear controles personalizados y de usuario.

No os llevéis a engaño por mis comentarios. El libro es muy bueno, lo explica todo perfectamente, pero la tecnología me ha desilusionado un poco. No sé, esperaba más. No más complejidad (que ya tiene bastante), sino más facilidad y menos picar código (aunque sea XAML)… Sí, ya sé que tenemos el Expression Blend, pero creo que aprender a manejar esa bestia parda tampoco es tarea de un rato…

Visual Studio 2010 Beta 2 y C++

Por fin anoche tuve un rato -y ganas- para instalarme la Beta 2 de Visual Studio 2010 en mi ordenador secundario, y por fin podré contar lo que llevo callándome bastante tiempo por el NDA de ser MVP… porque las novedades de Visual C++ 2010 son muchas y potentes, y seguro que a más de uno le voy a dar una alegría si no lo sabe ya por otras fuentes.

Pese a que hay cosas que ya son públicas desde hace mucho tiempo, voy a contarlas todas poco a poco aquí, y lo más seguro es que veáis más entradas mías sobre puntos concretos. No van en ningún orden de importancia, ni siquiera personal (bueno, sí, las que más me molan van al final), y antes voy a contar mi experiencia sobre la instalación.

Instalando. Primero lo instalé en mi máquina secundaria, un AMD X2 con 2GB de RAM y Windows 7 x86 Ultimate en inglés, pero antes tuve que desinstalar la versión anterior, de la que no diré más salvo que pude limpiarla sin problemas.

OJO CON DESINSTALAR LOS NUEVOS RUNTIMES DEL VISUAL C++ 2008 que el producto instala. Estos deben dejarse o correremos el riesgo de que luego nos peten la mitad de los programas que tengamos instalados. Considero que es una mala cosa eso de instalar runtimes no BETA dentro de una instalación BETA (o peor aún ni siquiera ALPHA), pero bueno, el Scatérgoris es de ellos.

Estuve probando varios programas y funcionaban bien, pese a la lentitud del IDE, que a veces se queda como autista o simplemente te ignora, frente a otras en las que la respuesta está casi adelantada al clic, así que me decidí a instalarlo en mi máquina principal, ya sabéis, un Q4 con 8GB de RAM y una espuerta de discos duros.

Si tenéis el SDK de Silverlight instalado, la instalación de la BETA 2 petará casi al final. Aunque no es ningún problema, ya que luego podéis desinstalar el SDK e instalarlo a mano a partir de la carpeta WCUSilverlight del DVD de instalación de esta misma BETA. Otro efecto adverso no tiene.

MSBUILD. Hasta la versión 2008, el sistema de construcción de proyectos era el llamado VCBUILD, que como su nombre indica es una especie de sistema de makefiles con esteroides. Pero el sistema es bastante obsoleto, y sólo era usado por Microsoft para Visual C++ ya que desde hace tiempo para los demás productos se viene utilizando MSBuild, que viene a ser lo mismo pero más moderno, basado en XML.

A mi personalmente es algo que me da igual porque no lo he usado más que integrado en el IDE y desde el IDE, así que tampoco sé muy bien qué ventajas tiene uno sobre el otro, aunque quizás la mejor de todas es que ahora el sistema de construcción es el mismo para todos los lenguajes.

No obstante, parece ser que las posibilidades de extensibilidad del más moderno son significativamente mejores que las del anterior, y supongo que serán útiles para aquellos que realicen compilaciones de gran tamaño.

Eso quiere decir que es necesario convertir los proyectos "vcproj" a "vcxproj", cosa que en esta BETA 2 se hace sin mayor problema, pero que en versiones anteriores fallaba estrepitósamente.

MFC. Aquí las novedades son relativamente pocas respecto al Feature Pack del VS2008SP1, pero alguna hay, como el restart manager, que es una extensión que, si tu aplicación peta, es capaz de recuperar tus documentos sin pérdida, o al menos eso es lo que proclaman. Parece ser que es la misma técnica y medios que se usan en, por ejemplo, Office, y lo cierto es que alguna que otra vez sí que me ha salvado el culo.

Luego tenemos los Task Dialogs, que son estas ventanas nuevas que vienen con Vista y 7 que permiten comunicación rica con el usuario, como la ventana de copiar archivos y similares.

image

Arriba podéis ver un ejemplo sacado de la documentación. La verdad es que no está nada mal, y se puede construir una ventana así con muy pocas líneas en C++.

SafeInt es una nueva biblioteca que permite manejar enteros con protección de desbordamiento en operaciones aritméticas, cosa que ni la biblioteca de C ni la de C++ tienen. Está basada en plantillas, de modo que al principio su uso puede resultar un tanto confuso. Un ejemplo sacado de la documentación:

SafeInt<uint>((uint)~0) > -1

devolverá cierto, mientras que si se hace con enteros normales, el resultado será falso. Para los legos, lo que estamos haciendo es una forma rápida de poner a unos todos los bits de un entero sin signo. ~0 es cero invertido, es decir, todo unos. Como lo moldeamos a un entero sin signo, eso significa que no importa el tamaño del tipo, estará lleno de unos de cabo a rabo. Ese valor, para un entero sin signo, es tropecientos mil trillones de trillones o más. Si se hace una comparación como

((uint)~0) > -1

el compilador comparará la pauta binaria. En ambos lados de la comparación, la representación binaria es la misma, todo unos, por lo que el compilador devolverá falso ya que para él ambos valores son iguales. Sin embargo, cuando usamos la versión segura, uno se asegura de que, efectivamente, tropecientos mil es mayor que menos uno.

C++ Estándar. También hay novedades en este aspecto, a ver si de una vez el comité se pone de acuerdo, que les cuesta más que a los políticos hablar de urbanismo. Lo que iba a ser el C++09 es muy posible que sea C++10 o superior. En fin.

La palabra reservada auto pierde su significado anterior (¿pone todavía alguien auto en las variables locales?) y pasa a indicar que la variable así cualificada es una cuyo tipo viene definido por el resultado de su valor-r. Para que me entendáis,

auto i=3;

significa que i es un int.

Las funciones lambda son el producto estrella de esta nueva futura revisión. Son un paso más allá de los punteros a función y los functors, ya que son funciones sin nombre que se pueden guardar en una variable… esto… de tipo auto (y esta es la razón que explica el cambio de significado de dicha palabra).

He dicho auto porque es la mejor forma de declarar un lambda y asignarlo a algo, y si no a ver quién es bonico que me dice el tipo de un lambda que toma tres enteros y devuelve un número en coma flotante sin llenar la declaración de paréntesis, asteriscos y demás menesteres.

Hay más novedades, como el operador decltype que devuelve el tipo de una expresión indicada. También están los declaradores de referencias a valores-r, que como su nombre indica declaran una referencia a un valor-r. Con static_assert tenemos la posibilidad de indicar aserciones en tiempo de compilación. Aunque creo que no pertenece al estándar, se crea la palabra reservada nullptr (y __nullptr) para asignar un puntero a nulo sin importar si estamos en C++ o en C++/CLI.

Si os fijáis, casi todas estas características están para dar un soporte eficiente a los lambdas. No voy a explicar aquí nada más de ellos porque pienso hablar largo y tendido sobre los mismo aquí… o en mi futuro libro si saco ganas para terminarlo.

Otras. Hay más novedades, como la eliminación de los caracteres trigráficos por defecto (se pueden activar), o una nueva opción de optimización de perfilado guiado. Para el que no lo sepa, un trigráfico es una secuencia de tres caracteres que se usa para especificar uno cuando el editor no lo tiene. De esta forma era como, hace muchos años, se podían poner ciertos caracteres inexistentes en los teclados, como ??) para indicar la llave de cierre ]. El estándar en ellos creo que especifica 10 diferentes.

Editor gráfico de Ribbons. Como lo lees. Visual C++ 2010 trata las Ribbons como un recurso más y proporciona un editor gráfico muy similar al de los cuadros de diálogo (que por cierto, también traen nuevos componentes largamente deseados), pudiendo escribir eventos y relacionar la Ribbon con partes del código. Ésta se almacena en un fichero XML embebido en el ejecutable, lo que seguro va a dar para algunos trucos que intentaré.

EL BOMBAZO: Para terminar, el bombazo. Cuando me enteré fue un bombazo, y he estado muchos meses comiéndome las uñas para que no se me escapara, y quizás haya que anunciarlo con letras bien gordas y a otro color:

¡¡VUELVE EL CLASS WIZARD!!

Sí señor, el magnífico, el inigualable, el incopiable, el ínclito Class Wizard. Así que ya no tenéis que seguir usando la morralla esa del Visual C++ 6.0 de los años de Maricastaña con un compilador todavía más obsoleto que uno que me sé y me callo. De todos modos, partes del mismo siempre han estado presentes, si bien algo camufladas.

Y para muestra, un botón:

image

Concurrencia y más concurrencia

Quienes hayan seguido mi podcast sobre Hilos en .NET se habrán dado cuenta de que la concurrencia bien entendida no es trivial ni de lejos, y eso que yo sólo cubrí los aspectos más básicos y por separado, vistos uno a uno. Quien no lo haya hecho y sienta curiosidad por el tema, puede acceder aquí, registrarse, y bajarse el vídeo y la solución de ejemplo (hay que ir hacia abajo hasta encontrar mi presentación).

Herb Sutter es uno de los mayores gurús de C++, de hecho fue, en conjunción con otros de su mismo nivel, el que desarrolló el C++/CLI (como prueba patente de ello, la traducción que Octavio Hernández y yo hicimos de su Rationale).

Pues bien, el amigo Herb mantiene en lo que antes era la revista Doctor Dobb’s Developer Journal y que ahora es un website dedicado al desarrollo, una columna llamada Effective Concurrency en la que habla, cómo no, de la concurrencia… desde el punto de vista de C++.

Ya os lo dije, hablar de todo esto y no citar ni C++ ni Win32 es como hablar de lana sin nombrar a las ovejas, así que es inevitable que la mayoría de elementos en relación a este tema tengan un trasfondo relacionado con un sistema operativo concreto y con C ó C++.

No obstante, siempre se pueden hacer extensivas a nuestro lenguaje favorito, en este caso C# y/o .NET, sobre todo cuando el autor expresa sus ideas con C++ pero explicadas al más alto nivel posible, como es el caso que nos ocupa.

El artículo sobre concurrencia de Sutter de este mes está destinado a cómo evitar la misma ocultándola dentro de métodos síncronos. Básicamente nos da ideas, en inglés, eso sí, sobre cómo adaptar código lineal existente a código que aproveche los nuevos equipos multinúcleo:

· Avoid Exposing Concurrency

· Más artículos del autor sobre concurrencia.

Parafraseando a David Salgado, happy reading.

Hemos leído: Vandevoorde & Josuttis: C++ Templates. The complete guide

El título de guía completa hace justo honor a su nombre, ya que no creo que haya vida en relación a las plantillas más allá de este libro, y si la hay no es más que combinación de lo visto aquí (ejem, obviemos a BOOST).

Está dividido en cuatro partes bastante independientes entre sí, y casi dedicadas a diferentes públicos. La lectura resulta a veces un poco engorrosa, con expresiones como La razón de la sinrazón que a mi razón se hace, de tal manera mi razón enflaquece que con razón me quejo… Esto… digo: The name of a template parameter of a template template parameter can be used only in the declaration of other parameters of that template template parameter p.103). Ahí es nada, aunque si uno lo piensa bien, está diciendo que el nombre de los parámetros que sean a su vez parámetros de una plantilla anidada sólo se pueden usar en la declaración de la misma y no fuera de ella. No obstante eso no evita que de repente tengas que ir a cambiarte los fusibles porque se te han fundido, o notes cómo el cerebro te sale derretido por la nariz…

Ciertamente no han sido pocas las veces que puesto la guía de lectura al principio del capítulo y/o sección y me he ido a dar una vuelta o a ver la tele. De todos modos esta complejidad es inherente en un texto de este tipo, obviamente no dedicado a principiantes en el lenguaje C++.

Primera parte. Hace un recorrido completo por las plantillas, y está dedicado al programador que las use ya construidas por terceros (como en la STL) o que vaya a hacerlas pero de forma casual. El contenido es completo, es decir, en esta primera parte ya está el libro entero, aunque con pocos aspectos prácticos y de implementación.

Segunda parte. Vuelve a recorrer la primera parte pero desde el punto de vista de un implementador de bibliotecas, asumiendo el contenido básico y profundizando en los detalles más técnicos y en los tiquismiquis de las plantillas, que al parecer no son pocos. Personalmente considero que esta parte es demasiado técnica y demasiado enfocada al mínimo detalle y de poca utilidad para alguien que simplemente quiera saber más. Esta parte termina con un capítulo dedicado a la futura dirección que podrían tomar las plantillas, aunque parece ser que, más de siete años después de escribir el libro, todavía no hay nada concreto.

Tercera parte. De nuevo esta parte es para el usuario accidental (es un decir), por lo menos la primera mitad de ella, ya que tiene un enfoque eminentemente práctico, mostrándonos para qué pueden servirnos las plantillas mejorando la calidad y eficiencia de nuestro código. A destacar cómo sustituir el polimorfismo dinámico por estático con plantillas así como nuevas versiones del patrón Bridge con un enlace más estático. También clases Trait y Policies (que no sé cómo traducir al castellano, pero que básicamente son clases intermedias que hacen de adaptadores genéricos para evitar la proliferación de código), y en general todo lo relacionado con programación genérica.

Luego se centra en la herencia con plantillas y pasa a temas más esotéricos, como la metaprogramación y el uso de las plantillas para realizar cálculos y optimizaciones en tiempo de compilación, técnica que usan algunas bibliotecas matemáticas para mejorar el rendimiento. Como guinda final, explica un código fuente que genera números primos en base a los errores creados por el compilador al parsear dicho fuente, amén de otros ejemplos como el cálculo de potencias o raíces.

Cuarta parte. Aquí volvemos al rol de creador de bibliotecas, de hecho explica y fundamenta clases plantilla para disponer de una especie de reflexión, punteros automáticos o inteligentes, n-tuplas y finalmente functors (que básicamente son clases que representan punteros a función -algo así a los delegados de C#, aunque más bien sería la base en la que bebieron los citados delegados).

Cómo desinstalar completamente tu C++ Builder 2009/2010

[Actualización 12/10/2009]
Para más INRI con este tema, ayer descubro que el desinstalador ni siquiera es capaz de borrar las entradas del menú incio, así que ya sabéis, es muy posible que sigan estando enlazadas a ningún lado. Por otro lado, si habéis instalado Rave Reports, también hay que desinstalarlo a mano (es decir, desde Programs and Features) y luego borrar las correspondientes entradas del menú inicio.

Texto Original:
Siguiendo con el tema del día de ayer, y uno, que es más cabezón que mi hermano, que tropezó y se cayó escaleras abajo en casa de mis padres y partió tres escalones de granito antes de que la masa no inercial de su azotea lo hiciera quedar a media altura con las patas parriba, se volvió a instalar la versión 2009 tras haber borrado la 2010.

Haciéndole un poco de justicia a Embarcadero, hay que reconocer que la 2009 funciona algo mejor, pero sólo algo. Como botón de muestra, con dicha versión es imposible depurar en ningún sistema x64 si no se aplica un parche binario a una DLL del IDE, cosa que ha sido solucionada no gracias a CodeGear/Embarcadero, sino a un chavalín que puebla los mundos de Internet: Oalf.

Y los propietarios del producto, en lugar de incorporar el parche a alguna de las actualizaciones, simplemente te dan el enlace al blog si berreas mucho en los foros públicos. Bien para Olaf, mal para Embarcadero, muy mal.

Bueno, pues como iba diciendo, anoche instalé la versión 2009, que tuve que actualizar al último parche para que funcionara en mi Windows 7 x64… con prácticamente el mismo resultado que la 2010. Si bien algunas cosas funcionaron algo mejor, como el hecho de que ahora sí, ahora parte de la personalización realizada a través del TActionManager se grababa y se recuperaba bien, pero ojo, sólo parte.

Otras cosas que siguieron sin funcionarme fue todo el tema del Docking, y ahí dejé de probar. No descarto que esto último sea desconocimiento propio, pero visto lo visto, más vale IDE viejo y conocido que nuevo y peor por conocer. Además, ¿ha visto alguien alguna aplicación hecha con C++ Builder que use algún sistema de Docking? Yo no, aunque quizás debería extenderlo, o mejor dicho, reducirlo a la pregunta de si ha visto alguien alguna aplicación hecha en C++ Builder.

Yo pensaba que con la entrada de Embarcadero como propietario de las herramientas se iban a poner las pilas, pero no ha sido así, y la primera versión enteramente sacada bajo las alas de esta empresa quizás haya sido todavía peor que la infame versión 6. Ya sabemos que hay una crisis global galopante, y que hay que amortizar los dineros gastados en comprar CodeGear, pero sinceramente, ha sido peor el remedio que la enfermedad, eso de sacar una versión a medio terminar y que hace más agua que un colador quizás pueda ser la puntilla con la que se termine de matar al producto…

Aparte de sentirme muy, pero que muy defraudado, me da mucha lástima que algo con la potencialidad que tiene Delphi/C++Builder esté siendo miserablemente matado por su propio creador. Si creyera en eso del destino y de la fatalidad, diría que C++ Builder es un producto con gafe, pero por desgracia el gafe lo crean los mismos propietarios de la herramienta.

Con tristeza y lágrimas en los ojos te digo adiós para siempre, C++ Builder…

***

Bueno, vamos a lo que vamos. Voy a explicar cómo borrar completamente C++ Builder, o lo más completamente que se pueda hacer. Partimos de una KB de Embarcadero, esta, que reúne los pasos necesarios, pero antes una puntualización: Si sabe qué hay que borrar, ¿Por qué cojones el desinstalador no lo borra?. Sí, ya sé que lo que queda por borrar son cosas porisaca, pero quizás el desinstalador debería preguntar si quieres un borrado completo o no. Otros lo hacen.

Yo voy a explicarlo para Windows 7 x64, pero vale igual para Windows Vista x64. Y si os preguntáis por qué lo explico si ya está contado en la KB, veréis que el proceso es algo diferente y que hay cosas que no están donde dicen que están, etc.

  1. Desinstala el producto “Rad Studio” desde “Programs and Features”.
  2. Desinstala la ayuda desde el mismo sitio (esta, por ejemplo, no viene en la KB).
  3. Si tienes ganas, reinicia, pero no es obligatorio.
  4. Borra las carpetas que cuelguen de “C:Program files (x86)” que tengan el nombre de Embarcadero o CodeGear.
  5. Borra las carpetas que cuelguen de “C:Program Files (x86)Common Files” con el nombre de BDE.
  6. Vete a “C:Program Data” y borra todas las carpetas que empiecen con un UIID o con un número y que estén ocultas y comprimidas. Ojo con este paso, es el más peligroso de todos si tienes algún otro producto instalado con la misma mierda de instalador que instala el C++ Builder. La KB da una clave del registro en donde están especificadas las claves, que en la versión de 64 bits está en HKEY_LOCAL_MACHINE SoftwareWow6432NodeMimarSinanInstallAwareIdent.Cache, pero en mi caso la clave está vacía. También puedes borrarla si no tienes más productos de este instalador.
  7. Borra del registro las claves con el nombre de CodeGear, Embarcadero y Borland que estén situadas en las ramas:
    1. HKEY_LOCAL_MACHINESOFTWARE
    2. HKEY_CURRENT_USERSOFTWARE
    3. HKEY_LOCAL_MACHINESOFTWAREWow6432Node
    4. HKEY_CURRENT_USERSOFTWAREWow6432Node
    5. La KB da otras claves que no existen, al menos en mi ordenador.
  8. Borra la carpeta “Rad Studio” de “C:UsersPublicDocuments”, y de paso también de “Mis Documentos”.
  9. Vete a tu profile, C:Users<usuario>AppData, y poda en Roaming las carpetas Embarcadero y CodeGear. Aquí es donde, entre otras cosas, se almacena la licencia del producto, que creo no vale entre instalaciones.
  10. Vete a C:Windows y usa el buscador para borrar una buena espuerta de ficheros. C++Builder 2009 tiene la versión 12 en los nombres de los ficheros, C++ Builder 2010, 14 (como todo buen estúpido, no quiere poner 13, pero da igual, la versión 2010 es la 13, como así lo es la del Office 2010, por mucho 14 que pongan). En las versiones de 32 bits estos ficheros suelen estar en C:WindowsSystem32, y en las de 64, en C:WindowsSysWoW64.
    1. Borra cualquier cosa con extensión BPL, que son las DLL del C++ Builder, que ellos llaman “packages”.
    2. Borra “*120.jdbg” y “*140.jdbg”, aunque podría valer sólo con la extensión.
    3. “*120.xml” y “*140.xml”
    4. “bdeadmin.*”
    5. “cc32*.dll”, que son los runtimes del C++ Builder.
    6. “midas.*”
    7. “xerces*.dll”

Hala, y eso es todo. El paso 6 resulta cuando menos curioso. En esas carpetas se guarda una copia de los instaladores y ficheros de instalación que vienen en el DVD del producto, y ante cada nuevo parche que instalemos, tendremos una nueva copia de los ficheros, de modo que con cuatro parches como tiene el C++ Builder 2009, será un giga y pico por instalación, es decir, sobre 5 GB de datos que no sirven para nada… Yo no sé quién será el lumbreras al que se le ha ocurrido tamaña barbaridad, pero se merece un premio; y me temo que no es el único producto que hace algo así, si no me equivoco, Office 2003 también usa una aproximación similar. En fin, que el espacio en disco duro está barato y la inteligencia cara, ya que si al menos sirviera para que los parches se pudieran desinstalar… Pero no, pese a toda esa morralla, la única forma de desinstalar un parche es reinstalar el producto…

Borland C++ 2010: No es oro todo lo que reluce

El que siga habitualmente este blog habrá visto varias entusiásticas entradas sobre el producto C++ Builder 2010, que fue durante varios años mi herramienta de desarrollo preferida (lo que también sabréis si me leéis), llegando hasta el punto de ser un furioso borlander al más puro estilo del fundamentalista linuxero. Luego, cansado de ella, la abandoné.

Y como es habitual cuando transcurre el tiempo, las cosas se van difuminando y perdiendo nitidez. Recuerdo que el abandono se produjo por la enorme cantidad de bugs que el producto tenía (sobre todo con ActiveX y COM), así como porque, año tras año, el producto era prácticamente el mismo pero con más problemas.

Pero el tiempo pasa, uno crece y llega a pensar que no sería para tanto, que quizás la culpa de muchos de los problemas se debieran al Layer 8 y no al producto en sí, máxime cuando no tengo acceso al código fuente de entonces y no sabría discriminar…

Así que uno le echa un tiento al C++Builder 2009, pero no tiene tiempo ni ganas de entrar en profundidad, pese a haber encontrado varios problemas que fueron resueltos por la gente de Embarcadero incluyendo un parche binario a una DLL… Y entonces llega la siguiente versión, la 2010 con unas maravillosas mejoras, como la vuelta a la compilación en segundo plano (algo que creo que se perdió en el paso de la versión 6 a la siguiente), la colocación de los componentes en la barra de tareas (que también se perdió en versiones posteriores a la 6) y el acceso a las entretelas del IDE. Otros detalles sí que son novedades, como el soporte multitáctil o la mejora en los visualizadores del depurador…

***

Ahora debemos cambiar de tercio. Todos sabemos que a fecha de hoy no existe ningún producto decente para el uso de las news, ya sea de pago o gratuito. El Opera tiene sus cosas raras, cuando se le va la pinza la arma bien gorda, el Windows Live Mail es una mierda pinchada en un palo. El Thunderbird quizás sea el que mejor vaya de todos, pero adolece también de varios problemas que no han sido solucionados desde la época en que venía integrado en el navegador Mozilla. Forté Agent no está mal, pero es toda una odisea configurarlo y la interfaz se ha quedado bastante obsoleta y, aparte de ser de pago, al menos los problemas que tiene son siempre los mismos y no presenta comportamientos aleatorios. El MesNews tampoco está mal, pero en mi caso me da infinitos problemas de conexión…

(Por favor, absteneros de comentarios sobre "a mí me va bien" y similares. Te lo puedo garantizar: efectivamente, "a ti te va bien", pero eso no quiere decir que mañana te la líe parda, y si no, tiempo al tiempo.)

Añadamos que en MAC no existe ningún cliente que se precie, todos son prácticamente basura. Por lo tanto llevo bastante tiempo con la idea de hacer un producto conforme a mi gusto, y sé que hay gente que lo está esperando con beneplácito. Así que hace como cosa de un mes me lié la manta a la cabeza y me puse en serio con lo que será el zxNewton… y entonces comenzó una etapa de mucho trabajo que hizo que apenas pudiera dedicar tiempo al programa ya que prácticamente todo mi tiempo libre se iba en trabajar.

No obstante algo hice, como bien sabe la gente de las News de Lechado…

***

… Y entonces volví a descubrir por qué había abandonado C++ Builder, porque fue con este producto con el que me decidí a hacerlo, ya que es muy posible que futuras versiones (no my lejanas) funcionen también en MAC y Linux. Podía haber elegido QT, pero parece ser que en MAC da muchos problemas, así que me decidí a hacer dos códigos fuentes: C++Builder para Windows y aprender a programar en MAC nativo en Objetive C y luego duplicar el código.

¿Por qué C++Builder y no MFC? Pues porque el primero es como .NET pero en C++ [casi] de verdad. Y porque la VCL ha evolucionado hacia algo bastante potente…

Por ejemplo, la VCL tiene un componente que se llama TActionManager que en conjunción con otros permite una personalización completa del programa. Puedes mover barras de herramientas, cambiar de sitio botones, añadir/quitar elementos, todo ello ya hecho con soltar tres o cuatro componentes en la ficha y ser un poco cuidadoso a la hora de codificar.

Otro aspecto que me mola es que soporta herencia visual, puedes heredar una ventana de otra sin muchos aspavientos ni complicaciones, y encima es prácticamente imposible romper la sincronía entre el editor visual y el de código.

Más: no usa el registro si no quieres, puedes guardarlo todo en ficheros en el lugar que quieras. La jerarquía de objetos es muy limpia y coherente, y todos los componentes son guardables a disco sin muchos aspavientos.

Pero eso es la teoría. Os cuento mis problemas. En Windows Vista x64 el editor de código no funciona muy bien, no formatea el código de forma automática, a veces se hace la picha un lío con los cierres de los paréntesis. En Windows 7 x64 el comportamiento del editor es algo más estable, pero tiene sus cosas.

El equivalente del IntelliSense muchas veces no funciona igual que en Visual C++, y cuando lo hace es lento de cojones, y no existe la posibilidad de usar el Visual Assist X o similar.

La ayuda es una mierda. Ni la online ni la local tienen apenas contenidos, con muchos problemas de enlaces que te llevan a la parte de Delphi o que contienen elementos mezclados de los dos lenguajes. Se nota que está compuesta desde el código fuente apenas comentado…

Si eso fuera poco, el IDE es incapaz de enlazar con el elemento adecuado. Si bien a esto ya nos tiene acostumbrados la MSDN y el Visual Studio, en C++ Builder es todavía peor, mucho peor (y yo que pensaba que no podía serlo).

Hay opciones del IDE que no funcionan, es decir, elijas la opción que elijas, el IDE va a la suya, y cuando vuelves a mirar está la que no has elegido.

En depuración el IDE peta sistemáticamente. Bueno, no peta, se queda autista y tienes que matarlo. No es que pase mucho, pero pasa una vez cada hora o así. Cuando pones un punto de interrupción y vas a continuar, siempre te pregunta si quieres seguir porque detecta que el código fuente ha sido modificado sin haberlo sido.

***

Eso en cuanto a elementos genéricos del entorno. En elementos específicos que he usado en el programa, tenemos más problemas, en este caso dentro de la VCL. Para que os hagáis una idea: tengo un form padre que es la que guarda el estado de la ventana, tamaño y demás. De ahí heredan las demás ventanas. En la principal hay un TActionManager que controla toda la UI, los dockings y la personalización. La parte principal es un TPageControl anclado a la ventana marco que permite pestañas. Cada pestaña es un control heredado de TFrame y que es el que realmente tiene todo el comportamiento de la aplicación.

Los marcos son como ventanas pero sin ventana, de forma que puedo anclarlos donde quiera ya que deben ser hijos de una. Es decir, si el usuario quiere que un marco (por ejemplo el del correo) esté flotando como una ventana independiente, yo creo la ventana y saco el marco de donde esté anclado y lo pongo como hijo de la misma. De esta forma no hay destrucción ni creación de nada, sólo movimiento de componentes.

Pues bien, todo esto, que está documentado y no es nada fuera de lo ordinario, presenta los siguientes problemas (quizás alguno se debe a desconocimiento personal, y si es así y la gente de Embarcadero me responde, así lo corregiré):

Las ventanas no responden a las órdenes de Docking, ya sea automático o manual. Es decir, sacas un elemento de un lugar para acoplarlo a otro y lo más que ocurre es que se quede flotando si te deja desacoplarlo. Esto es así para al menos el Frame, los elementos en el interior del mismo y la Toolbar del programa. En el caso del Frame ni siquiera deja sacarlos, y lo único que puedes hacer con la Toolbar es dejarla flotante y ya no la puedes volver a anclar a ningún lado.

El TActionManager, pese a volcarse y cargarse de disco (veo el fichero y su interior), no recupera la UI modificada, ni siquiera los botones cambiados con el asistente. Lo guardas modificado y lo cargas con los valores por defecto.

Hay componentes que al ponerlos dentro de un Frame en tiempo de ejecución generan una excepción y petan la aplicación.

***

¿Os parece poco? Pues sólo llevo con el C++Builder unas 10 horas. Imaginaros cuando lleve varios meses. Y eso que ya le ha salido un parche, que he aplicado pero que apenas ha arreglado nada.

Me da pena, mucha pena, pero la cruda realidad es que el producto continua siendo tan malo como cuando lo abandoné en su versión 4… Bueno, tan malo no, peor, ya que por lo menos en aquellos años el IDE no fallaba ni petaba ni hacía cosas raras… En fin, que como no se pongan las pilas… Yo creo que voy a abandonar… y empezar de nuevo con QT, MFC u otra solución que se me ocurra…