C++ como problema
El primer problema es C++. Siempre me ha parecido un mal lenguaje; un lenguaje supuestamente de alto nivel diseñado de manera que su código fuente sea un superconjunto de C, que es un lenguaje de bajo nivel, ya suena raro. Sobre eso tenemos que mucha gente opina que no es un buen diseño de lenguaje, por diferentes razones: Por ejemplo, Jamie Zawinski dice "C++ es una abominación. Todo está equivocado en él de todas las maneras posibles", para seguir luego "cuando programas en C++ nadie puede ponerse de acuerdo en qué 10% del lenguaje es seguro usar. Siempre hay alguien que decide 'necesito usar plantillas'. Y acabamos descubriendo que no hay dos compiladores que implementen las plantillas de la misma forma".Las críticas cubren tres razones principales:
- el lenguaje es mucho más grande y complejo de lo necesario
- el problema de elegir que subconjunto se usa hace difícil la compatibilidad
- los mensajes de error cuando se usan plantillas son crípticos y complejos de usar
En las prácticas los dos primeros problemas son irrelevantes, ya que nuestro código es un callback al que el sistema llama repetidamente, lo que simplifica mucho el código. Sólo el último problema fue real, encontrando algunos errores relacionados con std::vector<float>, que usamos para recibir los valores del laser. Esos errores eran siempre extraordinariamente oscuros y difíciles de aislar, pero afortunadamente fueron pocos y en seguida pude localizarlos.
Gestión de versiones
El mayor problema, con diferencia, fue que el conjunto de versiones cambiaba continuamente. Para hacer una idea, empezamos con la versión 3.0 de introrob, y acabamos con la 3.8, pasando por todas las intermedias, si recuerdo bien. Normalmente esos cambios de versión eran por problemas en el código, y no eran importantes en sí, salvo que, al no tener el código de introrob (ni el mío, mea culpa) bajo control de versiones, tenía que pasar 30 minutos cada vez que entraba en el laboratorio inspeccionando el código nuevo, para ver si había cambiado algo en la parte que modificábamos nosotros, y luego mezclando el código nuestro en la nueva versión.Casi al final del proceso me di cuenta de que la solución habría sido poner yo bajo git las diferentes versiones de introrob que nos proporcionaban, en una rama tipo "vendor", y mezclarlas con mis modificaciones en ramas "practica1", "practica2", etc
Sin embargo la idea se me ocurrió tarde, cuando ya estábamos en la versión 3.8 y no llegué a implementarla.
Imposibilidad de desarrollar en mis equipos
Cuando probé la instalación en mis equipos, encontré un error: gazebo daba una "violación de segmento". Depurándola con gdb encontré que era en código de OpenGL. El profesor me confirmó que no tenía arreglo, y que pasaba en equipos con determinadas implementaciones de OpenGL. En mi caso un chip gráfico Intel.
Puesto que todos los ordenadores de casa tienen chips gráficos Intel de varias generaciones, cosa normal porque, no juego en el ordenador y desarrollo habitualmente para servidores y no he hecho programación gráfica desde hace la tana de años, resulta que no pude usar el entorno de simulación en mis máquinas, viéndome obligado a ir a los laboratorios linux en Móstoles cada vez que quería probar código.
