c++ - gui - gtk linux
¿Por qué se creó el sistema GObject? (4)
La introducción
De acuerdo, entonces, después de la versión 0.60 de GTK+ , los diseñadores se dieron cuenta de que para el desarrollo y el progreso futuros, todo el conjunto de herramientas debía reescribirse para estar orientado a objetos.
Ahora, dado que C no es compatible con OOP, para proporcionar orientación a objetos y heredades heredadas, crearon el Sistema GObject . Ahora, la creación del sistema GObject debe haber requerido tiempo de desarrollo, más dependencias, más problemas, pero tuvieron que crearlo para proporcionar capacidades de orientación de objetos al lenguaje de programación C. Pero en ese momento, había otra solución que proporcionaba exactamente eso, ¡ C ++ !
La pregunta
¿Por qué los desarrolladores de GTK + simplemente no usaron C ++?
La explicación
Quiero decir, ¿por qué perder el tiempo creando una biblioteca completa en lugar de utilizar una solución probada por muchos de los proyectos? No me malinterpreten, no estoy tratando de convertir esta publicación en una cosa C vs C ++ (he tenido suficiente de eso en los foros, gracias). Solo quiero saber las razones y los problemas que hicieron que los diseñadores de GTK + tomaran la decisión que tomaron.
De la wiki vinculada a en la pregunta:
Historia (De Wikipedia )
GTK + fue originalmente diseñado y utilizado en el Programa de Manipulación de Imágenes de GNU (GIMP) como un reemplazo del juego de herramientas Motif; en algún momento, Peter Mattis se desilusionó con Motif y comenzó a escribir su propio conjunto de herramientas GUI llamado el kit de herramientas GIMP y había reemplazado con éxito a Motif por el lanzamiento de GIMP en 0.60. [3] Finalmente GTK fue reescrito para ser orientado a objetos y fue renombrado como GTK +. Esto se usó por primera vez en la versión 0.99 de GIMP.
Esto debería indicar que el object-oriented paradigm no era un criterio primordial para la elección del lenguaje para GTK (que es diferente de GTK +) y esa característica se agregó mucho más tarde.
El sistema de tipo GObject hace cosas que no puedes hacer en C ++. Por un lado, permite la creación de nuevas clases en tiempo de ejecución, y lo hace de una manera que es independiente del lenguaje: puede definir una nueva clase en Python en tiempo de ejecución, luego manipular instancias de esa clase dentro de una función escrita en C, que Ni siquiera es necesario saber que Python estuvo involucrado alguna vez.
GObjects está destinado a ser independiente del lenguaje. Tiene tipado dinámico, y debe compararlo con un sistema de tiempo de ejecución como COM, .NET o CORBA, en lugar de con lenguajes específicos. Si ingresas a idiomas, las características son más del lado de Objective-C que de C ++.
No puedo responder directamente la pregunta, al menos en lo que respecta a GTK. Esa respuesta recae en los desarrolladores de GTK +, por lo que tendrás que buscarlos y preguntarles. Pero en cuanto a por qué uno querría agregar un sistema orientado a objetos a C, en lugar de usar C ++, hay muchas razones. Los tres en los que pensaría inmediatamente son
Complejidad del lenguaje: mientras que C es un lenguaje bastante simple, C ++ es tremendamente complicado, con soporte para la mayoría de las cosas (no todas) C, así como conveniencias como referencias, y también características orientadas a objetos y un lenguaje complejo de plantillas. Y has visto el nuevo sistema de valores: lvalues, rvalues, glvalues, prvalues y xvalues - ¿eh? Hay mucho más de lo que podría hablar. Con el tiempo, C ++ se vuelve manejable, pero sigue siendo excesivo para querer algunas características orientadas a objetos en C.
Control: si los diseñadores fueran con C ++, se quedarían estancados con la filosofía de C ++. Por ejemplo, la herencia múltiple es una idea controvertida, y por una buena razón. Por diseño, el sistema GObject está diseñado solo para admitir herencia simple, lo que simplifica drásticamente las jerarquías de herencia. Si los diseñadores fueran con C ++, no habría manera de limitar a los usuarios a un único sistema de herencia. La herencia múltiple es solo un ejemplo: estoy seguro de que hay muchos otros lugares en los que el sistema GObject difiere de la ideología de C ++.
Interoperabilidad: Esta es probablemente una gran. Aunque hay algunos lenguajes con los que C ++ interactúa limpiamente, el hecho es que C ++ no es tan bueno en interoperabilidad. Sin embargo, la interoperabilidad con C casi se da por sentada. C a menudo se describe como la lengua franca de los lenguajes de programación, ya que forma el estándar de facto para la interoperabilidad. Al diseñar una API C, los diseñadores de GObject abrieron la puerta al desarrollo de GTK + en cualquier cantidad de idiomas.