Una vez escuché un dicho, podríamos vivir sin Linux, pero definitivamente no podríamos vivir sin GCC. Parece que solo hay un compilador de C en el mundo de Linux. ¿Hay alguna alternativa a gcc? ¿Los programadores bajo AIX/HPUX/Solaris usan solo gcc para desarrollar programas?¿Hay alguna alternativa a gcc para hacer un desarrollo práctico bajo * nix?
Ciertamente hay al menos una alternativa a gcc en Linux: clang es un compilador de C (y dialectos relacionados, aunque por lo que yo puedo ver, la interfaz de C es mucho más maduro que los otros dialectos) utilizando LLVM. Apple apoya el desarrollo de LLVM & amigos, creo; es útil para su Grand Central Dispatch/OpenCL cosas, IIRC.
Sun Studio 12 ahora está disponible como free download para Linux (sabores X86, al menos) y todas las variantes de Solaris. No sé cómo se compara la versión X86/Linux del compilador, pero la versión del compilador de Sparc/Solaris es capaz de producir un código significativamente más optimizado que GCC, y el depurador es mucho más poderoso que GDB. La desventaja es que te quedas atascado con una GUI inactiva basada en Java para el depurador.
En términos de compiladores C, no podría prescindir de gcc. Pero C no es el único juego en la ciudad. Muy a menudo armé pequeñas aplicaciones rápidas en Python y algunas más complicadas en Java (Sun one, not gcj).
No seleccionaría su idioma para una aplicación. Es una opción mucho mejor para elegir su aplicación y luego hacerlo en un idioma que se adapte. Si C es todo lo que sabes, úsalo. Pero encuentro que la enorme biblioteca de estructuras de datos y algoritmos en Java (y Python) es invaluable para arrancar código rápidamente.
No sé mucho sobre HPUX o Solaris pero, incluso en AIX, prefiero usar gcc en lugar de xlC, el compilador de IBM.
Si está buscando un compilador C ligero y rápido TinyCC (vea también Wikipedia) definitivamente merece la pena echarle un vistazo.
Sin embargo, hay algunas desventajas. Solo realiza muy pocas optimizaciones y la última versión estable solo es compatible con la arquitectura x86, aunque ya existe soporte experimental x86_64 en la rama de desarrollo.
Por ahora, probablemente me quedaré con GCC para cualquier programa serio que considere estos defectos de TinyCC.
El único caso de uso en el que TCC podría ser realmente útil hoy en día es usarlo como intérprete para el código C. No he medido el rendimiento, pero me puedo imaginar que un pequeño "script" en C puede competir con suavidad con el código de Bash (en términos de velocidad de ejecución y de análisis).
¡Los desarrolladores incluso tuvieron éxito en la interpretación de un kernel de Linux 2.4 en tiempo real y lo iniciaron de inmediato! Hay una imagen ISO flotando alrededor que funciona perfectamente en Qemu.
Como GCC se basa en un código que data de varias décadas atrás cuando no había mucho conocimiento sobre estructuración de código, uso apropiado de patrones de diseño, etc., los desarrolladores de GCC mantienen una base oxidada y propensa a errores. Lamentablemente, el código es un desastre y no hay alternativa a una reescritura completa.Esa probablemente también sea la razón por la cual los desarrolladores de LLVM también se acercaron a Clang y comenzaron desde cero. A largo plazo, realmente espero que haya un reemplazo adecuado para GCC, que hace todo conceptualmente desde el principio. Clang suena como un reemplazo digno, aunque no estoy completamente cómodo con su elección de usar C++, pero ese es otro tema. :)
"Adoro en el altar de los patrones de diseño". Tarde o temprano, puede aprender que no todo es un patrón de diseño, y no pueden usarse para * todo *. Los compiladores son intrínsecamente peludos. Entonces ... tal vez es un desastre. No, tal vez no. Es un desastre. Pero "patrones de diseño" manuales y una "estructuración de código" aún menos definida no van a resolver eso, porque parte de ese desorden (la mayor parte, apostaría) * tiene que ser así *. O mira el "desastre" del kernel de Linux. Ah, lo olvidé: es así porque esos fanáticos de Linux no saben nada sobre el desarrollo adecuado de SW. Tiene que ser así, el profesor me lo dijo. –
Considere el compilador PathScale Path64 y Open64. Sólido, de código abierto, con una larga historia. Muy popular en computación de alto rendimiento, y también una buena plataforma para la investigación académica.
También hay libfirm/cparser que implementa la mayoría de las extensiones de gcc y genera código optimizado (actualmente para 32 bits x86 y SPARC): http://pp.ipd.kit.edu/firm/
En HP-UX puede utilizar cualquiera aCC o gcc –