Libertonia || Comments || ¿Por qué en C?


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)

Yo no lo tengo tan claro (none / 0) (#7)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Wed Jul 28th, 2004 at 10:43:38 AM CET
(Información Usuario) http://speedball.servemp3.com

No me he documentado para este hilo, sino que hablo más por lo que recuerdo de las discusiones al respecto de los problemas de gcc 2.7, egcs y gcc 2.9x. Sobre todo enmarcadas ante los problemas que se presentaban tanto con el kernel como con el C++.

Creo recordar que uno de los problemas más importantes eran la perdida de rendimiento a la hora de enlazar de forma dinámica bibliotecas de clases, cosa que afectaba negativamente a KDE. Eso unido a que el soporte de C++ era muy incompleto, por lo que la libqt requería precompiladores extra (ahora no se como va la cosa: me pasé a GNOME).

No he hablado del sistema de llamada a los métodos, sino el enlazado, el link. En el caso de enlazado estático el rendimiento es idéntico, ya que la faena de enlazado se produjo en lo que habitualmente llamamos compilación. Pero en el caso de usar enlazado dinámico, el enlazado se produce en tiempo de ejecución, con lo que en el caso de usar C++, al ser los objetos a enlazar más complejos que los objetos de C, el enlazador tarda más y por tanto el programa tarda más y nos aparece más lento.

Ese problema tenía negros a los desarrolladores de KDE, y si miras en las listas de discusión de la época del KDE 1.x verás como muchos reniegan de Linux y del gcc.

Se lleva desde los tiempos del egcs intentando lograr un ABI decente para C++ que ayudase al enlazador dinámico en su tarea. Ni lo consiguieron con el egcs, ni con el gcc 2.95, ni esta excesivamente claro si con los gcc 3.x lo han logrado, a pesar de su estandarización. Estandarización inexistente, ya que no podemos mezclar demasiado binario de diferentes versiones de compilador.

Tal como ya he dicho, escribo de memoria basandome en las impresiones que me dejaron las discusiones y problemas que había hace cinco o seis años y posiblemente este muy equivocado.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

El enlazador y el montador de enlaces (none / 0) (#8)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 11:59:35 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Creo recordar que uno de los problemas más importantes eran la perdida de rendimiento a la hora de enlazar de forma dinámica bibliotecas de clases, cosa que afectaba negativamente a KDE.

En realidad el problema al que te refieres, el del prelink ¿no?, era un problema del montador de enlaces. El ld.so sufría bastante para resolver todos los símbolos de una aplicación de KDE y especialmente el tiempo de arranque se disparaba. En realidad no es un problema de C++ (a una aplicación escrita en C con el mismo número de dependencias y resoluciones le pasaba lo mismo) pero sí que es verdad que se notaba más en C++ porque habitualmente en ese lenguaje se hacen más resoluciones (piensa en un método virtual en una biblioteca compartida, repetido en varias vtables y resuelto cada vez).

El problema se resolvió modificando el enlazador (no confundas enlazador con montador de enlaces) de manera que organizase la información para que permitiera el cacheado de símbolos y simplificara el número de las secciones reloc. Consulta la documentación sobre la opción combreloc, que es activa por defecto.

En resumen que, si es eso a lo que te refieres, desde luego no es/era un problema del ABI de C++.

Ese problema tenía negros a los desarrolladores de KDE, y si miras en las listas de discusión de la época del KDE 1.x

Bueno, creo que en tiempos del KDE 1.x el menor de los problemas de g++ era ese. El compilador de C++ de GNU fue francamente penoso hasta que se metió Redhat de por medio (tampoco es que hoy por hoy sea nada del otro jueves, pero esa es otra historia).

De los bugs más escandalosos que recuerde de esa época estan el de las plantillas con parámetros, el del orden de los parámetros en los constructores (según como los ordenases podía funcionar o no :-D), etc. Además había dos ramas: la del egcs (bastante mejor) y la de gcc y lo que compilaba en la primera a veces (muchas) no lo hacía en la segunda, y por versiones eran incompatibles a nivel binario también.

Una de las razones con más peso que hizo que la gente de Gnome escogiera C fue que, cuando empezaron, no había compilador ni medio decente de C++ que fuera libre. Pienso que viendo el panorama actual escoger C++ hubiera sido la decisión de futuro.

[ Padre ]

En eso estoy de acuerdo (none / 0) (#9)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Wed Jul 28th, 2004 at 01:29:11 PM CET
(Información Usuario) http://speedball.servemp3.com

Tengo claro que la razón por la que GTK+ y GNOME están programados en C es claramente por una razón histórica y no por una razón tecnológica del año 2004, y que seguramente resultaría más fácil programar GNOME usando C++.

Pero de todas formas el problema que le encuentro a GNOME, en mi opinión, no es la selección del lenguaje de implementación, sino más bien de diseño. Tiene muchas tecnologías bonitas, pero no trabajan conjuntamente, y es que se nota que no tenían nada claro que es lo que querían hacer.

Las incomodidades del C las deberían ver los que programan el GNOME en si mismo, pero si realmente GNOME llegase a ser independiente del lenguaje, las aplicaciones deberían poderse programar sin problemas usando C, C++, Objective-C, Perl, Python, Pascal, ADA, etc.

Linux, glibc, XFree86, etc. están programados en C puro y duro pero uno puede desarrollar aplicaciones para Linux sin picar ni una sola línea de C. Lo mismo debería (y pretendían) suceder con el entorno de escritorio, sea GNOME, sea KDE, sea AfterStep...

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]

La independencia del lenguaje (none / 0) (#11)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 04:33:27 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Las incomodidades del C las deberían ver los que programan el GNOME en si mismo, pero si realmente GNOME llegase a ser independiente del lenguaje, las aplicaciones deberían poderse programar sin problemas usando C, C++, Objective-C, Perl, Python, Pascal, ADA, etc.

Eso sería lo ideal pero en la práctica no funciona. El API C de Gnome no puede ser independiente del lenguaje.

Primero porque los bindings y los wrappers no siempre están sincronizados con el api canónico C. Aunque hagamos los bindings de forma automática a partir de la última versión del api oficial hay lenguajes que necesitan más información de la que C necesita y de la que hay en las cabeceras, así que siempre habrá que hacer ajustes manualmente.

Segundo porque C impone limitaciones a los bindings que no son evidentes a los programadores de otros lenguajes y que hacen que la integración con los mismos chirrie. Un par de ejemplos:

Hasta hace una versión, el wrapper de C++ de Gnome y Gtk (que es fantástico, por cierto) obligaba a cazar las excepciones localmente o a no usarlas, porque si una excepción remontaba el stack podría darse el caso que estuviera apilada una función C del api nativo y sin información adicional para propagar la excepción (con fallo fatal como resultado).

En Python, cuando subclasificas un control de Gnome o Gtk y la aplicación recibe un evento de él, ésta no recibe el objeto de la subclase que generó el evento como sería de esperar sino de su clase padre, sin posibilidad de hacer algo como un dynamic_cast<> en C++.

Tercero porque los bindings sólo van en una dirección: si yo no quiero derivar mis clases con el api C sino comodamente desde C++ lo puedo hacer, pero mi amiguete que programa en Ruby no puede usar mis clases directamente ni yo las que escriba él extendiendo el api.

Todas estas pegas son las que resuelve .NET sobre el papel. Con Mono el api sería el mismo para todos los lenguajes soportados. Las mismas posibilidades/limitaciones para todos, no habría problemas de sincronización y funcionaría "en ambas direcciones": lo que escribas en lenguaje1.NET yo podré usarlo en lenguaje2.NET directamente sin más, y viceversa.

[ Padre ]

Motivos de la elección de C (none / 0) (#10)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Wed Jul 28th, 2004 at 04:09:11 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Una de las razones con más peso que hizo que la gente de Gnome escogiera C fue que, cuando empezaron, no había compilador ni medio decente de C++ que fuera libre.

Mi impresión es que la portabilidad a otros sistemas pesó mucho en la decisión de usar C. Al fin y al cabo, un compilador ANSI C es fácil de conseguir casi en cualquier plataformas. No tenéis más que fijaros en los gpointer, gint's y demás para ver por donde voy. Aunque unos cuantos libertonianos seguro que pueden contarnos fehacientemente de lo poco que ha valido eso.

Lo de la portabilidad, por cierto, es una obsesión permanente del proyecto GNU. Por ahí es por donde le viene a GNOME (en mi opinión).

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]

Un poco de todo (none / 0) (#12)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 05:17:14 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Cuando me refería a que lo eligieron porque había un compilador libre de C, gcc, debería haber añadido que además multiplataforma y ampliamente disponible.

Supongo que en la elección de C pesaron varias cosas:

Gtk+ es un api en C y si Gnome extiende Gtk+ a priori usar el mismo lenguaje parece la elección adecuada. No había ningún otro toolkit C++ "libre".

Tradicionalmente la programación de interfaces gráficas en los Unix se ha hecho en C: en parte por la amplia difusión de Motif (que es C y es horrible) y en parte porque los compiladores de C++ eran una castaña. Había disponible un montón de mano de obra voluntaria si se escogía C. De la misma manera ya había mucho trabajo hecho en forma de aplicaciones C libres listas para ser "gnomificadas" e integradas en el escritorio (como xscreensaver, gestores de ventanas, etc).

La posibilidad de hacer bindings: es mucho más fácil hacer un wrapper de C que de C++. La premisa de poder programar en varios lenguajes era prioritaria al principio, aunque al final en eso se hayan quedado a medio camino.

Etc, etc. No se consideró un factor sólo pero sí parece a toro pasado que la decisión fue equivocada. Quizás se arregle con Mono si al final Gnome lo adopta.

[ Padre ]

¿Por qué en C? | 19 comentarios (19 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda