¿Por qué Qt utiliza Moc para señales y ranuras?

Las plantillas son un mecanismo incorporado en C++ que permite al compilador generar código sobre la marcha, dependiendo del tipo de los argumentos pasados. Como tales, las plantillas son muy interesantes para los creadores de frameworks, y usamos plantillas avanzadas en muchos lugares en Qt. Sin embargo, existen limitaciones: Hay cosas que puedes expresar fácilmente con plantillas, y hay cosas que son imposibles de expresar con plantillas. Una clase de contenedor vectorial genérico es fácilmente expresable, incluso con especialización parcial para tipos de puntero, mientras que una función que configura una interfaz gráfica de usuario basada en una descripción XML dada como cadena no es expresable como plantilla. Y luego hay una zona gris en medio. Cosas que puedes hackear con plantillas a costa del tamaño del código, la legibilidad, la portabilidad, la usabilidad, la extensibilidad, la robustez y, en última instancia, la belleza del diseño. Tanto las plantillas como el preprocesador C se pueden estirar para hacer cosas increíblemente inteligentes y alucinantes. Pero sólo porque esas cosas se puedan hacer, no significa necesariamente que hacerlas sea la elección de diseño correcta. El código, por desgracia, no está pensado para ser publicado en libros, sino compilado con compiladores del mundo real en sistemas operativos del mundo real.

He aquí algunas razones por las que Qt utiliza el moc:

La sintaxis importa

La sintaxis no es sólo azúcar: la sintaxis que utilizamos para expresar nuestros algoritmos puede afectar significativamente a la legibilidad y mantenimiento de nuestro código. La sintaxis utilizada para las señales y ranuras de Qt ha demostrado ser muy eficaz en la práctica. Es intuitiva, fácil de usar y de leer. Las personas que están aprendiendo Qt encuentran que la sintaxis les ayuda a entender y utilizar el concepto de señales y ranuras, a pesar de su naturaleza altamente abstracta y genérica. Esto ayuda a los programadores a diseñar correctamente desde el principio, sin ni siquiera tener que pensar en patrones de diseño.

Los generadores de código son buenos

El moc de Qt (Meta Object Compiler) proporciona una forma limpia de ir más allá de las facilidades del lenguaje compilado. Lo hace generando código C++ adicional que puede ser compilado por cualquier compilador C++ estándar. moc lee los archivos fuente C++. Si encuentra una o más declaraciones de clase que contengan la macro Q_OBJECT, genera otro archivo fuente C++ que contiene el código metaobjeto para esas clases. El archivo fuente C++ generado por el moc debe compilarse y enlazarse con la implementación de la clase (o puede ser #included en el archivo fuente de la clase). Normalmente moc no se llama manualmente, sino automáticamente por el sistema de compilación, por lo que no requiere ningún esfuerzo adicional por parte del programador.

moc no es el único generador de código que utiliza Qt. Otro ejemplo destacado es el uic (User Interface Compiler). Toma una descripción de la interfaz de usuario en XML y crea código C++ que configura el formulario. Fuera de Qt, los generadores de código también son comunes. Tomemos como ejemplo rpc y idl, que permiten a los programas u objetos comunicarse a través de los límites de procesos o máquinas. O la gran variedad de generadores de escáneres y analizadores sintácticos, siendo lex y yacc los más conocidos. Toman una especificación gramatical como entrada y generan código que implementa una máquina de estados. Las alternativas a los generadores de código son los compiladores pirateados, los lenguajes propietarios o las herramientas de programación gráfica con diálogos unidireccionales o asistentes que generan código oscuro en tiempo de diseño y no de compilación. En lugar de encerrar a nuestros clientes en un compilador de C++ propietario o en un Entorno de Desarrollo Integrado concreto, les permitimos utilizar las herramientas que prefieran. En lugar de obligar a los programadores a añadir el código generado a los repositorios de código fuente, les animamos a añadir nuestras herramientas a su sistema de compilación: más limpio, más seguro y más en el espíritu de UNIX.

Las interfaces gráficas son dinámicas

C++ es un lenguaje de propósito general estandarizado, potente y elaborado. Es el único lenguaje que se explota en una gama tan amplia de proyectos de software, abarcando todo tipo de aplicaciones, desde sistemas operativos completos, servidores de bases de datos y aplicaciones gráficas de gama alta hasta aplicaciones de escritorio comunes. Una de las claves del éxito de C++ es su diseño de lenguaje escalable, que se centra en el máximo rendimiento y el mínimo consumo de memoria, al tiempo que mantiene la compatibilidad con ANSI C.

A pesar de todas estas ventajas, existen algunos inconvenientes. Para C++, el modelo de objetos estático es una clara desventaja frente al enfoque de mensajería dinámica de Objective C cuando se trata de programar interfaces gráficas de usuario basadas en componentes. Lo que es bueno para un servidor de bases de datos de gama alta o un sistema operativo no es necesariamente la elección de diseño correcta para un frontend de interfaz gráfica de usuario. Con moc, hemos convertido esta desventaja en una ventaja, y hemos añadido la flexibilidad necesaria para afrontar el reto de la programación segura y eficaz de interfaces gráficas de usuario.

Nuestro enfoque va mucho más allá de lo que se puede hacer con plantillas. Por ejemplo, podemos tener propiedades de objeto. Y podemos tener señales y ranuras sobrecargadas, lo que resulta natural cuando se programa en un lenguaje en el que las sobrecargas son un concepto clave. Nuestras señales añaden cero bytes al tamaño de una instancia de clase, lo que significa que podemos añadir nuevas señales sin romper la compatibilidad binaria.

Otra ventaja es que podemos explorar las señales y ranuras de un objeto en tiempo de ejecución. Podemos establecer conexiones utilizando la llamada por nombre a prueba de tipos, sin tener que conocer los tipos exactos de los objetos que estamos conectando. Esto es imposible con una solución basada en plantillas. Este tipo de introspección en tiempo de ejecución abre nuevas posibilidades, por ejemplo GUIs que se generan y conectan desde los archivos XML UI de Qt Widgets Designer.

El rendimiento de las llamadas no lo es todo

La implementación de señales y ranuras de Qt no es tan rápida como una solución basada en plantillas. Mientras que emitir una señal supone aproximadamente el coste de cuatro llamadas a funciones ordinarias con implementaciones de plantillas comunes, Qt requiere un esfuerzo comparable a unas diez llamadas a funciones. Esto no es sorprendente, ya que el mecanismo de Qt incluye un marshaller genérico, introspección, llamadas en cola entre diferentes hilos y, en última instancia, scriptability. No depende de un excesivo inlining y expansión de código y proporciona una seguridad en tiempo de ejecución sin igual. Los iteradores de Qt son seguros, mientras que los de sistemas más rápidos basados en plantillas no lo son. Incluso durante el proceso de emisión de una señal a varios receptores, éstos pueden ser eliminados de forma segura sin que su programa se bloquee. Sin esta seguridad, tu aplicación se bloquearía eventualmente con un error de lectura o escritura en memoria libre difícil de depurar.

Sin embargo, ¿no podría una solución basada en plantillas mejorar el rendimiento de una aplicación que utiliza señales y ranuras? Si bien es cierto que Qt añade una pequeña sobrecarga al coste de llamar a un slot a través de una señal, el coste de la llamada es sólo una pequeña proporción del coste total de un slot. La comparación con el sistema de señales y ranuras de Qt se realiza normalmente con ranuras vacías. Tan pronto como haces algo útil en tus slots, por ejemplo unas pocas operaciones de cadena simples, la sobrecarga de la llamada se vuelve insignificante. El sistema de Qt está tan optimizado que cualquier cosa que requiera el operador new o delete (por ejemplo, operaciones con cadenas o insertar/eliminar algo de un contenedor de plantillas) es significativamente más caro que emitir una señal.

Aside: Si tienes una conexión de señales y ranuras en un bucle interno apretado de una tarea crítica para el rendimiento e identificas esta conexión como el cuello de botella, piensa en utilizar el patrón estándar de escucha-interfaz en lugar de señales y ranuras. En los casos en los que esto ocurra, probablemente sólo necesite una conexión 1:1 de todos modos. Por ejemplo, si tienes un objeto que descarga datos de la red, es un diseño perfectamente sensato utilizar una señal para indicar que han llegado los datos solicitados. Pero si necesitas enviar cada byte uno a uno a un consumidor, utiliza una interfaz de escucha en lugar de señales y ranuras.

Sin límites

Como teníamos moc para señales y ranuras, podíamos añadirle otras cosas útiles que no se podían hacer con plantillas. Entre ellas están las traducciones de ámbito a través de una función generada en tr(), y un sistema avanzado de propiedades con introspección e información extendida de tipos en tiempo de ejecución. El sistema de propiedades por sí solo es una gran ventaja: una herramienta de diseño de interfaz de usuario potente y genérica como Qt Widgets Designer sería mucho más difícil de escribir -si no imposible- sin un sistema de propiedades potente e introspectivo. Pero esto no acaba aquí. También proporcionamos un mecanismo dinámico qobject_cast<T>() que no depende del RTTI del sistema y, por tanto, no comparte sus limitaciones. Lo utilizamos para consultar de forma segura interfaces de componentes cargados dinámicamente. Otro campo de aplicación son los metaobjetos dinámicos. Podemos, por ejemplo, tomar componentes ActiveX y en tiempo de ejecución crear un metaobjeto a su alrededor. O podemos exportar componentes Qt como componentes ActiveX exportando su meta objeto. No se puede hacer ninguna de estas cosas con plantillas.

C++ con moc nos da esencialmente la flexibilidad de Objective-C o de Java Runtime Environment, manteniendo las ventajas únicas de rendimiento y escalabilidad de C++. Es lo que hace de Qt la herramienta flexible y cómoda que tenemos hoy en día.