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)

Mis humildes respuestas (4.66 / 3) (#4)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Tue Jul 27th, 2004 at 09:55:35 PM CET
(Información Usuario) http://speedball.servemp3.com

Tengo opiniones más o menos deformadas de todos los puntos, así que me voy a poner a la tarea ;)

¿no funcionaría exactamente igual de bien un kernel en C++?

Se puede escribir el kernel en C++, incluso hay algún sistema operativo básicamente escrito todo él en dicho lenguaje.

El primer problema es de rendimiento. El C++ es claramente más lento que el C debido a que el mecanismo de enlazado de clases es más complejo que el de simples funciones. El segundo problema tiene el mismo origen: al ser complicado el enlazado de clases, ha costado dios y ayuda a gcc crear un ABI (interficie binaria para aplicaciones) claro y coherente para C++, con lo que hasta la versión 3.0 no tenía un soporte decente de C++.

Además, en el caso de Linux, al querer ser algo similar a UNIX, tiene un diseño claramente dirigido a C. Un kernel diseñado para C++ sería algo muy distinto a un kernel tradicional UNIX.

¿O por lo menos un driver?

El driver debe enlazarse con el código C del kernel, con lo que volvemos a encontrarnos con el problema del ABI.

Claro que con otros diseños de kernel eso no tiene porque pasar. Por ejemplo en el caso del Hurd los drivers van en espacio de usuario y pueden usar no sólo llamadas al kernel, sino cualquier librería. En Hurd se podría escribir (en teoría) el driver en cualquier lenguaje, incluso en Perl. Hurd no es un kernel estilo UNIX, de hecho tiene una capa de emulación POSIX por encima.

Por otro lado no siempre se escriben kernels en C/C++ y similares. Nada impide programarlos en Pascal, Modula-2, Java... ¿Java? pues si, si consideras la JVM una arquitectura igual que lo pueda ser i386, y de hecho existe un JavaOS. Evidentemente esta pensado para ese aborto (por no llegar a ver la luz) que fueron los NC y para esa idea de Sun de micros que directamente ejecuten bytecode Java (evidentemente para NC y cosas similares).

El éxito de C es que se acerca mucho al ensamblador siendo de alto nivel, esta muy estandarizado y hay muchos programadores entrenados en él. La ventaja de C++ es que se parece mucho al C.

Lo que ya me parece la repera es tener un entorno gráfico en C, como GNOME [...] algunos de los muchísimos problemas tienen su origen en el uso de C

No estoy deacuerdo en absoluto. Primero porque las mismas razones que recomiendan usar C en el kernel siguen siendo válidas: cuando se empezo GNOME el gcc no daba la talla con C++, y de eso saben mucho los desarrolladores de KDE.

La orientación a objetos es una metodología de programación, igual que lo pueda ser la programación estructurada. Usar clases no hace que el programa sea orientado a objetos. Es cierto que es mucho más fácil hacer programas orientados a objetos usando C++ que C porque queda todo mucho más natural. El problema de GNOME no es que no use objetos, el problema en mi opinión es que no se han pensado demasiado bien la clasificación de esos objetos y que la cosa ha ido creciendo de forma caótica.

Intentaré explicarlo: no han creado una clase fichero para encapsular el tratamiento de los ficheros desde un origen, sino que se han quedado con las utilidades que ya daba gtk+, que básicamente se diseñaron para que GIMP pudiese leer y guardar imágenes. Luego se han dado cuenta que las aplicaciones del escritorio tratan con ficheros, y que lo que da el GTK+ para el GIMP puede valer, pero para un escritorio "moderno"... así que se han puesto como locos a escribir unas clases megachulis de ficheros, lo han bautizado con el rimbonbante nombre de GNOME Virtual File System y se han quedado tan anchos. Pero claro, todo todito todo lo que había antes, ese mogollón de clases megachulis de la muerte que tarde o temprano utilizan un fichero están programadas usando las primitivas de ficheros de GTK+. Esta chapuza es de diseño, y se puede obtener exáctamente igual programando en C, en C++, en Java o en Python.

¿Como quieren arreglar el problema los chicos de GNOME? pues me temo que cagandola otra vez. En vez de rediseñar las puñeteras clases para que sean coherentes, quieren modificar las primitivas de GTK+ para que sean más vistosas. Si que el usuario verá una ventana de selección de fichero más aparente y espero que más cómoda (no hace falta gran cosa para lograrlo), pero lo lógico sería hacer que todas las clases que usan ficheros utilicen los procedimientos ofrecidos por GNOME-VFS, y así, por arte de magia potagia, no sólo podremos acceder a ficheros de diferentes medios (locales, compartidos, http, ftp...) desde el menú Archivo de las aplicaciones, sino que incluso las clases internas podrán acceder a esos ficheros sin que haga falta que el programa primero tenga que hacer una copia local en el tmp.

¿por qué será que todos estos desarrollos de base (entornos gráficos, gestores de ventas) se hacen en C o C++?

Evidentemente no es sólo la velocidad, también esta la facilidad. Si las llamadas básicas del sistema (en el caso que nos ocupa, glibc y xlib) estan escritas en C, lo más fácil para interactuar con ellas es usar C. Paul Graham puede tener razón, pero como resulta que la base del sistema operativo esta escrita en C, todos los demás lenguajes se han visto obligados a encontrar algún método para acceder a código C de una forma rápida y eficiente. Esta perfectamente documentado cómo hacerlo y muy estudiado qué métodos son los más eficientes, con lo que resulta casi un problema de libro hacer que cualquier lenguaje pueda comunicarse con C.

Una estúpida idea que me ronda por la cabeza tras cierto número de cervezas es crear un sistema operativo para 8086 basado en Python. De lo que se trata es de reprogramar el interprete de Python para que sólo utilice la BIOS original del PC y escribir en Python una interficie de usuario estilo a la de TurboPascal 4.0. Coger una máquina del tiempo y enseñarsela a IBM diez minutos antes de que Bill Gates les llame por teléfono :P. Evidentemente es absurdo: no hay máquinas del tiempo y meter un interprete Python en un 8086 hoy día no sirve para nada, pero tecnológicamente se puede hacer, y no se diferencia demasiado de lo que es el JavaOS o el proyecto Inferno. Hay muchas máquinas que se hicieron más o menos así, pero usando BASIC normalmente (pienso por ejemplo en el Sinclair QL y otras máquinas de la misma época que usaban M68K). De hecho no se porqué no hizo eso Bill Gates, supongo que porque le resultaba más barato comprar QDOS por $50000.

No sé, luego la gente se queja bastante de C++. Tanto que hasta han creado varias alternativas: Objective-C, Java, D (no, no es un chiste: es un lenguaje). Y de C no digamos; pero luego siempre se vuelve a ellos.

Creo que en realidad C++ y Objective-C se desarrollaron más o menos en paralelo y són dos aproximaciones diferentes a los objetos. Objective-C es mucho más canonica, y tiene una herencia clara de Smalltalk. C++ parece ser que ha ido un poco más a salto de mata. Digamos que C++ es C con objetos y Objective-C un lenguaje compilable orientado a objetos sintácticamente similar a C. Java sigue la idea de Objective-C, pero más o menos así: cogemos Smalltalk y le metemos la sintáxis del C++, ¡ah si!, y nos cargamos el browser de clases para que la máquina virtual quepa en una lavadora. Algún día me gustaría saber para qué coño querían meter los de Sun una JVM en una lavadora, pero quién dice lavadora dice teléfono móvil, navegador web, servidor de aplicaciones, etc.

Básicamente Java es una reimplementación de Smalltalk para los programadores de C++ ;^)

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

Puntualizando (4.50 / 2) (#6)
por jorginius ("jorginius" en Google Mail) a las Wed Jul 28th, 2004 at 01:42:20 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

El primer problema es de rendimiento. El C++ es claramente más lento que el C debido a que el mecanismo de enlazado de clases es más complejo que el de simples funciones

C++ no es más lento que C: el coste de llamar a un método es exactamente el mismo que el de hacer una llamada a función. El coste de llamar a un método virtual es el mismo que llamar a una función a través de un puntero a función (un nivel de indirección más).

Un característica de C++ es que todas las funcionalidades son "opcionales" (a diferencia de Objective C). Algunas pueden enlentecer o no. Las excepciones como las implementa gcc no tienen impacto en tiempo de ejecución, rtti y casts inteligentes siempre tendrán un coste... Pero puedes prescindir de ellas.

Por otra parte, el compilador de C++ tiende a escupir más código porque en un programa de C++ normalmente se hacen más cosas que en C y eso se nota en peso y en velocidad, pero código en C que hiciera lo mismo que C++ incluye de serie sería igual de lento, o más aún porque el compilador de C++ al menos sabe cómo optimizar código orientado a objetos.

Quiero decir: si quieres hacer programación orientada a objetos, C++ es posiblemente más rápido que C, y sin duda más cómodo. En otro caso, como C es casi un subconjunto de C++, puedes programar al estilo de C con tu compilador de C++ sin merma, como si fuera un compilador de áquel pero atiborrado de esteroides.

El segundo problema tiene el mismo origen: al ser complicado el enlazado de clases, ha costado dios y ayuda a gcc crear un ABI (interficie binaria para aplicaciones)

Nop, el problema ha sido otro. A diferencia de C, C++ no ha tenido un ABI estandar hasta hace poco y antes cada compilador implementaba el que mejor le parecía, así que enlazar código generado por distintos compiladores era bastante complicado. De la misma manera, mientras que llamar a una función C está chupado desde cualquier lenguaje, hacer lo mismo con C++ te obligaba a conocer el ABI del compilador primero.

En la versión 3.0 se decide reescribir entero el ABI de g++, al que no le pasaba nada más que no era estándar (como el de los otros compiladores), y adoptar el ABI oficial de reciente publicación.

Y aquí empieza el lío: aparte del problema de ingeniería de tener que reescribir parte de g++, de los bugs que se pueden introducir en la implementación y de que el nuevo es incompatible con el viejo, resulta que en el propio ABI estándar había bugs y ambigüedades en algunos puntos que se dejan al buen criterio del que hace el compilador (con lo que enlazar código generado por distintos compiladores sólo está resuelto en teoría). Todo esto ha tenido que irse ajustando "en caliente", en versiones supuestamente estables.

Hay muchas máquinas que se hicieron más o menos asi [monitor y interprete de BASIC de interfaz]. De hecho no se porqué no hizo eso Bill Gates

En el PC original hay espacio para el mapa de memoria para un intérprete de BASIC. Si no puede arrancar de disco estaba previsto que saltase al intérprete como último recurso. Yo tengo un IBM XT que se comporta de esa manera.

Supongo Microsoft se pondría en contacto con IBM en primer lugar para venderles el BASIC del PC. Luego vieron la oportunidad de meter la cabeza con el fiasco de DR y no sólo les vendieron el intérprete sino el sistema operativo.

Hace un tiempo hablamos por aquí de QDOS y de su leyenda :-) en Historia de Microsoft.

[ Padre ]

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