Programación General > C/C++
Programas Ejemplo
QliX=D!:
--- Cita de: "chuidiang" --- Me explico un poco más.
C o C++ standard no es limitado en el sentido de que puedes hacer lo que quieras con él y posiblemente de forma más eficiente que en cualquier otro lenguaje.
Sin embargo, en C o C++ standard no tienes ventanas, gráficos, comunicaciones por red, etc. Cualquier aplicación que quieras hacer en C++ que utilice esto o te haces tu mismo las librerias (debes saber un montón y echar otro montón de tiempo) o recurrir a librerías externas que pueden ser un standard en si mismas (opengl, allegro, qt, motif, etc), pero no forman parte de C++.
Al final, para hacer aplicaciones más o menos serias, siempre necesitas C++ y librerías ajenas al C++ standard que te faciliten la programación de gráficos, ventanas, comunicaciones, acceso a bases de datos, etc.
Ahora una duda. Hace tiempo la STL era una librería aparte que no venía con los C++ y debías descargarte aparte. ¿Forma ahora parte de cualquier C++ moderno que me baje?.
Se bueno.
--- Fin de la cita ---
Las STL ahora son parte del Estandar C++ de hecho todo compilador moderno decente que te bajes las tiene.
BCB, VC, Watcom las tienen.
Con respecto al hecho de no tener librerias para ventanas, accesos de red, etc, es sencillamente por que C++ es multiplataforma, por lo tanto deberia tener una interfaz distinta para cada sistema de ventanas del planeta, y para los sistemas de red tambien, cosa poco util y que sobrecargaria el lenguaje, por eso solo se deja las bases para construir lo demas.
chuidiang:
Lo de cambiar la interface para cada sistema operativo es parcialmente cierto.
C++ podría establecer una interface standard para red o gráficos, (igual que lo hace, por ejemplo, para acceso a ficheros independientemente de que el disco sea de ms-dos, windows o unix) y es problema de las implementaciones del compilador para una plataforma concreta el implementar esas interfaces y que funcionen bien.
Es similar a java, que define java.awt y javax.swing para ventanas. Luego el compilador de java para windows, para unix o para lo que sea debe implementar esos "botones" sobre el sistema de ventanas concreto. Cualquier java standard que te bajes tiene su librería de ventanas y funciona en cualquier plataforma que soporte java.
El resultado, al final, es que si quieres que tus fuentes C o C++ sean portables, no puedes usar librerías externas, es decir, ni ventanas, ni comunicaciones, ni bases de datos, etc. (o bien usar librerías externas que estén implementadas en esas varias plataformas).
Se bueno.
QliX=D!:
--- Cita de: "chuidiang" --- Lo de cambiar la interface para cada sistema operativo es parcialmente cierto.
C++ podría establecer una interface standard para red o gráficos, (igual que lo hace, por ejemplo, para acceso a ficheros independientemente de que el disco sea de ms-dos, windows o unix) y es problema de las implementaciones del compilador para una plataforma concreta el implementar esas interfaces y que funcionen bien.
Es similar a java, que define java.awt y javax.swing para ventanas. Luego el compilador de java para windows, para unix o para lo que sea debe implementar esos "botones" sobre el sistema de ventanas concreto. Cualquier java standard que te bajes tiene su librería de ventanas y funciona en cualquier plataforma que soporte java.
El resultado, al final, es que si quieres que tus fuentes C o C++ sean portables, no puedes usar librerías externas, es decir, ni ventanas, ni comunicaciones, ni bases de datos, etc. (o bien usar librerías externas que estén implementadas en esas varias plataformas).
Se bueno.
--- Fin de la cita ---
JAVA???? JAVA????..... <_<
Ok.
A los bifes:
Las AWT y SWING la verdad que son un desastre define una interfaz comun para el manejo de las ventanas en los ditintos sistemas operativos, que tiene que ser traducidas luego al API correspondiente y ver si la funcionalidad existe o si tieneque acoplar una serie de funciones para lograr esa funcionalidad, lo cual hace el sitema lento.
Aparte de que java utiliza el engine de Dibujo en 2d del sistema si no tiene soporte para el look and fell correspondiente y lo hace mas lento todavia el sistema.
No me parece buenoq ue la gente de C++ tenga que estandarizar eso pro que acota y limita a los desarrolladores a la forma del estandar y eso puede ser terrible.
slds.
chuidiang:
Java es lento principalmente por la filosofía del lenguaje en sí misma (bytecodes que corren en una máquina virtual, recolector de basura, ficheros .class que hay que ir cargando en ejecución, etc), no porque tenga que adaptarse a llamadas a la API.
OpenGL por ejemplo define unas funciones standard para gráficos, que está implementado en varias plataformas y que va rápido en todas ellas. C++ podía definir perfectamente funciones (y clases y ventanas y lo que haga falta) de forma standard. Es problema del que implementa el compilador el generar código nativo eficiente para la plataforma concreta.
Se bueno.
Navegación
[*] Página Anterior
Ir a la versión completa