Entrevista a Ion Gaztañaga sobre C++0x

Andaba yo leyendo un nuevo artículo acerca de C++0x, Ad-Hoc Meeting on Threads in C++ que repasa los temas abiertos para estandarizar los threads en el nuevo C++ cuando, entre tantos nombres ilustres, como Hans Boehm o Herb Sutter nombraban a Ion Gaztañaga y su papel Memory Mapped Files And Shared Memory For C++. Como me ha parecido muy interesante se me ha ocurrido hacerle una entrevista, y aquí está:

P. ¿Puedes hacer una introducción a tu persona y como has llegado a escribir una de las propuestas del C++0x que ahora se debaten para su estandarización

R. Hice una librería para Boost y ahí establecí contacto con Howard Hinnant. Howard, actualmente es el que dirige el grupo de trabajo de librerías (Library Working Group, LWG) del comité de estándar C++ y es realmente una persona muy dialogante y que sabe escuchar las ideas de todo el mundo. Le ayudé un poco con alguna de sus propuestas y de ahí surgió la idea de presentar un artículo propio. Howard me invitó a ir a la conferencia sobre threads y ha sido un auténtico honor estar ahí. Esta semana, el comité está reunido en Portland en sesión oficial y espero estar presente en la próxima reunión que se celebrará en Oxford, el mes de Abril.

P. Las propuestas que se están haciendo para el nuevo C++ ¿las ves todas positivas? ¿cuales te gustan más? ¿y menos? (a mi particularmente me gustan las de los threads, los sockets, las de las expresiones regulares y las incializaciones de contenedores... como escribí en Un vistazo a c++0x por Bjarne Stroustrup y Más sobre C++0x)

R. En general, no hay ninguna propuesta que me disguste, excepto la del Garbage Collector. En mi opinión el garbage collector no encaja en el actual C++ y me chirría bastante. Puede ser debido a prejuicios o a experiencias no muy satisfactorias con otros lenguajes que lo implementan, pero en general, no lo veo necesario y creo que no encaja en la filosofía C++. Pero será un tema muy discutido, sin duda.

Respecto a las demás propuestas, me parece que los threads son esenciales. No tengo conocimientos para evaluar seriamente un modelo de memoria, ya que yo estoy más centrado en estructuras de más alto nivel. En ese sentido, me gusta mucho la propuesta N2094.

También soy un gran fan de rvalue-reference. Creo que solventa un gran problema de rendimiento de C++, que es la generación de temporales, aunque no los elimina completamente. Mi otra debilidad es la propuesta de templates variadicos.

Hay otras propuestas que también me gustan bastante, como los conceptos o los módulos. De todas formas, creo que estas propuestas son menos necesarias que librerías esenciales para usos comunes de programación: funciones de red (sockets), memoria compartida, mapeo de ficheros, manejo de directorios, xml...

P. Crees que los compiladores tardarán menos en implementar estas características que lo que se tardó en implementar el C++98? ¿y los programadores en usarlas?

R. Creo que los programadores los usaran en cuanto estén disponibles. Creo que con la actitud actual de Microsoft de implementar el estandar, la adopción será más rápida que la del estándar C++98. Gcc ya tiene ramas experimentales que implementan templates variadicos, rvalue-reference y conceptos. Metrowerks ya ha implementado rvalue-reference.

P. ¿Crees positivo que un lenguaje se defina a través de un 'comité de estandarización'? ¿qué opinas del estilo 'software libre' de debate/implementación (tipo perl/python)?

R. El estilo "comité" es realmente largo y tedioso. Pero también es una garantía de estabilidad. Me asusta la posibilidad de que como Java, de
una versión a otra se declare obsoleta la mayor parte de la librería estándar. Estos es realmente desastroso para algunos sectores que usan C++, como sistemas críticos de larga duración donde la estabilidad es esencial. Para dar mayor dinamismo, creo que sin Boost, C++ estaría en una situación muy comprometida. El empuje de Boost ha sido clave para recuperar el dinamismo de C++ y creo que C++ está más fuerte que hace
unos años.

El estilo software libre es, en mi opinión, muy interesante, porque es muy dinámico y da buenos resultados e ideas. Creo que no es aplicable a C++ porque necesita una estabilidad mayor, pero podría pensarse en un
modelo híbrido donde se desarrollan librerías y nuevas funcionalidades en un estilo software libre (por ejemplo, gcc es pionero en implementar algunas propuestas) que luego pueden ser estabilizados y estandarizados si se consideran adecuados. Tener una implementación de referencia es muy importante para la estandarización, por lo que no considero ambos
métodos como incompatibles.

P. Añadir tantas cosas al lenguaje y a su librería estándar ¿no es demasiado ambicioso? ¿demasiado complejo?

R. Bueno, más complejo es implementar las librerías estándares de otros lenguajes, porque tienen un tamaño muy grande. Creo que la librería estándar no será un problema porque hay implementaciones libres como Boost que las empresas pueden usar y adaptar para su propio producto. El tema del compilador es más complejo, pero creo que el cumplimiento del estándar se ha convertido en un tema esencial para los usuarios del compilador. De hecho, este deseo de los usuarios fue lo que forzó a Microsoft a implementar el estándar.

P. Parece que una gran parte de las nuevas características van en la linea de aumentar la portabilidad entre sistemas ¿se conseguirá realmente facilitar la vida al programador en esa faceta?

R. Creo que vamos en el buen camino. Los threads serán una muestra de ello. Para el conjunto de librerías TR2, se va a proponer una librería de red, basado en Boost.Asio, que es un tema esencial, en mi opinión para la credibilidad de C++. Quedan todavía funciones como lanzamiento de procesos, comunicación entre procesos, mapeo de ficheros en memoria y otros.

P. ¿Qué opinas de C++/CLI?

R. No lo he usado, porque trabajo principalmente en aplicaciones portables ANSI C++. No me gustaría que fuera un nuevo episodio de "abrazar, extender y exterminar" de Microsoft y creo que la presencia de Herb Sutter ha sido vital para un trabajo leal entre ambos estándares. Así lo han manifestado muchos miembros del comité. Pero creo que no ha conseguido su objetivo de "revolución". Primero apostaron por C# y luego han cambiado a C++/CLI. La limitación de su portabilidad, ya que es un sistema basicamente Windows (Mono es una opción, pero no creo que pueda seguir el ritmo de Microsoft) hace que no sea interesante para mí.

P. Cuando se estandarizará C++0x? (en tu opinión) ¿cuando sabremos que número es la equis? :)

R. No tengo ni idea ;-) La intención es que sea C++09, pero prefiero que sea un buen estandar que incluya threads y otras propuestas que un estandar que salga antes pero no incluya esto. Mientras tanto, siempre está Boost.

Sólo me queda darle las gracias por su amabilidad así como por la cantidad y calidad de sus respuestas.

La misma entrada en BP

Diseño sencillo contra implementación correcta

Diseño elegante y sencillo frente a implementación correcta. No siempre están enfrentados, pero muchas veces si.

El tema me ha surgido leyendo un blog muy interesante, Thinking parallel, en el cual se discute si los mutex recursivos son buenos o no, que apunta a un excelente post en comp.programming.threads Recursive mutexes by David Butenhof. Las dos tesis contrapuestas son:

• Los mutex recursivos son buenos, porque ayudan a modularizar y a abstraer (diseño elegante y sencillo)
• Los mutex recursivos son malos: Del post de Butenhof:"Un diseño correcto y bien pensado no requiere mutex recursivos" (implementación que puede ser no correcta)

Lo cierto es que la tesis de Butenhof está muy bien argumentada y nos da pistas de cuando estamos haciendo las cosas mal:

El problema más grande de todos los problemas de los mutex recursivos es que animan a perder la pista de tu esquema de bloqueos y su ámbito (scope). Esto es mortal. Nefasto. Es el "comedor de threads". Has de coger los mutex durante el tiempo más corto posible. Punto. Siempre. Si estás llamando a algo con un mutex cogido es porque no sabes si está cogido o porque no sabes si la llamada lo necesita, entonces lo estas cogiendo demasiado tiempo.

Abstrayendo... ¿Que caracteriza (entre otras cosas) un buen diseño?

• No se repiten conceptos (fácilmente modificable)
• Es elegante (desde lejos, desde arriba, a nivel de relación entre objetos, módulos ...)
Es sencillo (en lo posible, para no complicar o entorpecer la implementación)

¿Que caracteriza (entre otras cosas) una buena implementación?

• No se repite código (mantenible)
• Es elegante (el código, de cerca, a nivel de función)
• Es correcto
• Es óptimo

Entre la sencillez del diseño y la optimización y corrección de la implementación es donde suele haber más problemillas. En lugar de rediseñar cuando se detectan errores de rendimiento el camino más fácil son los hacks, que cuando no son excelentes suelen embarullar el código y distorsionar el propósito del diseño.
En estos casos no habría que tener miedo de refactorizar el código y rediseñar si es preciso, aunque en un caso ideal habría que haberlo tenido en cuenta antes, como requisitos no funcionales, pero sin caer en la sobreingeniería. Difícil verdad ;)

Se podría decir que los mutex recursivos son un hack y por ese motivo usarlos con mucha precaución. Como dice el propio Butenhof (extensible a todos los hacks)

Los mutex recursivos son un hack. No hay nada erróneo si se usan, pero son una muleta. ¿Tienes una pierna rota o una librería? Bueno, usa una muleta. Pero al menos sé consciente de que la estás usando y porqué.

La misma entrada en BP