Barrapunto

Tu opinion me parece interesante, coherente y bien pensada.

Pero dejame apuntarte que no estupido dejar la cuestion del tamaño y velocidad a segundo plano a favor de la extensibilidad, mantenimiento y rehutilización. Por poner un ejemplo, no me importa perder un segundo en el inicio cargando plugins, teniendo en cuenta que en los ordenadores de mañana ese segundo desaparecera pero los plugins (es decir, su arquitectura) seguira ahi. Un ejemplo más claro es la arquitectura de componentes, un tanto pesado pero impresionante.

Esta claro que todo lo que puedes hacer en C++ puedes hacerlo en C, Pascal, Python o lo que quieras, ya que son lenguajes completos. Pero C++ creo que da un balance optimo entre velocidad y abstracción. Tambien es cierto que C++ es un lenguaje complejo, pero puedes evitar esa complicación con un diseño adecuado (como el de KDE, donde todo encaja en su sitio y las cosas salen solas.

C, C++, eficiencia, GTK+, ... pues usa D [digitalmars.com].

Hay versiones Linux y Windows, tiene un foro muy activo, el front-end es libre y se está portando para funcionar con GCC (aunque el compilador de Walter deja al gcc por los suelos).

Es un lenguaje en el que ya he escrito un par de programillas, y no le veo ninguna desventaja: sería como tener todo lo de C, C++, Java y Python en un lenguaje ...

Saludos

Si no usas la STL y otras basuras y sabes lo que haces, el C++ puede ser MAS eficiente (o igual, pero nunca menos) en velocidad y gasto de memoria que el C, para algoritmos complejos equivalentes y con las mismas salvaguardias.

¿Cómo lo sé? Hace 20 años que programo profesionalmente y tengo mucha experiencia con el ensamblador, ya que antiguamente era casi el único lenguaje que utilizaba. De vez en cuando examino el código que generan los compiladores para ver cómo traducen algunas partes críticas de mi trabajo o el de mi equipo, y ahí es dónde lo veo.

NOTA: He llamado basura a la STL porque así me parecen las implementaciones que he visto. Tal vez se puedan mejorar, pero, además, la especificación usual de la STL me parece un mal ejemplo de diseño, aunque contiene unas pocas buenas ideas.

C es un lenguaje totalmente imperativo, basado en las órdenes o algoritmos que utilizas; estas órdenes se apoyan o usan ciertas estructuras de datos que pueden ser incluso objetos, pero el centro del programa, el principal método de desarrollo, el corazón del programa sigue siendo el algoritmo. C++ es, sin embargo, un lenguaje orientado a objetos, donde la parte principal del programa, el verdadero enfoque que realiza el programador no es lo que el programa tiene que hacer, sino las estructuras que utilizan; estas estructruas (los objetos) se apoyan en órdenes y algoritmos, pero la base aquí son las estructuras de datos.

Por tanto, al pertenecer a distintos paradigmas, son útiles para uno determinado tipo de tareas. Por ejemplo, si quieres programar un driver no tiene mucho sentido utilizar clases y cosas por el estilo, pero para un programa de alto nivel como OpenOffice.org [openoffice.org] la orientación a objetos se hace tremendamente útil.

Es cierto que ambos pueden hacer lo mismo, de hecho, todo lenguaje capaz de implementar la Máquina de Turing (bendito Alan Turing [turing.org.uk]) tiene plena capacidad para hacer todo lo computable. Por poner un ejemplo, un lenguaje de tipo declarativo que implemente la Máquina de Turing, como ProLog [inria.fr], también es capaz de hacer lo mismo que C y C++, pero estaremos de acuerdo que no tiene mucho sentido programar KDE usando ProLog...

Si, pobrecito hablador, Gtk+ simula un sistema de objetos, y para ello ha de aportar cierta infraestructura, pero que la parte de interfaz gráfica necesite esa infraestructura (bastante minimalista), no significa que el conjunto de la aplicación se vea supeditado.

Si, pobrecito hablador, utilicé Gtk+ 1.2, y es realmente eficiente en consumo de memoria y en velocidad de ejecución.

Actualmente me encuentro portando la herramienta a Gtk2, ¿seguro que Qt 3.2 es mucho más eficiente que la serie de Gtk 2?. Agradecería algún comentario aclaratorio al respecto.

En realidad es incluso peor!

En C++ como el compilador entiende el sistema de objetos puede realizar optimizaciones que mejoran el rendimiento (por ejemplo resolver llamadas a metodos virtuales en tiempo de compilado) mientras que en Gtk todo se hace en tiempo de ejecucion.

Otro beneficio importante es que como los objetos se pueden crear en la pila no hay que andar reservando y liberando memoria para todo como es el caso de Gtk, que es un incordio.

Otra cosa es si hablamos de la STL o del uso de plantillas en general, que si no se tiene cuidado pueden hacer que los tamaños de los ejecutables crezcan sin control.

Si habeis leido el libro de Stroustrup ("The C++ Programming Language") vereis que cuidado tiene el tio en no hacer ninguna concesion a la perdida de eficiencia en los programas en beneficio de otras caracteristicas si no es absolutamente necesario.

Otra cosa es lo que luego cada programador ya haga por su cuenta y la atencion que le dedique a cuestiones como la eficiencia, el consumo de memoria, etc., y sobre todo con las prestaciones de los ordenadores de hoy en dia porque la mayoria de las veces no compensa ya preocuparse de esos temas.

Resumiendo, que en C++ se pueden hacer programas tan eficientes como en C, pero no es obligatorio ;-)