que repasa los temas abiertos para estandarizar los threads en el nuevo C++ cuando, entre tantos nombres ilustres, como
. 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.
