1383
Ya es oficial: el compilador GCC está cambiando a una implementación en C++. En el anuncio oficial se comenta que "el GCC Steering Committee y la FSF han aprobado el uso de C++ en el propio GCC. Por supuesto no hay razón para usar características de C++ sólo porque se puede. El objetivo es hacer un mejor compilador para los usuarios, no hacer un código base en C++." Visto en softlibre.barrapunto.com/article.pl?sid=10/05/31/1540255
menéame
Me ha costado encontrarlo, la habia leido hace tiempo en otra pagina, pero está poco extendido... www.redcientifica.com/gaia/reir/cpp_c.htm
Me he leído la entrevista, está muy bien
Sí, ya sé que es una broma, lo había captado. Sobre todo por la pregunta final:
¿Crees que esta entrevista es mentira?
Es mentira Es verdad
Pasando el ratón por encima de cada vínculo ves si es verdad o mentira.
#6 No es broma, un binario en C++ de un jodido Hello World me pesa mas que si lo escribo en C.
La entrevista es broma, lo dice claramente la página. Y si de verdad fuera una broma, el hombre no se hubiera molestado en trabajar en el estándar C++0x, ni en escribir un libro que va ya por su tercera edición y enésima tirada.
En fin, ya que estoy, he hecho un Hello World en ambos lenguajes
En C++ he utilizado la biblioteca iostream y en C la stdio.h, en éste caso el Hello World me da 678 bytes más (9148B vs 8470B).
Luego he querido usar la biblioteca cstdio en C++, dándome tan solo 67 bytes de más (8537B vs. 8470B).
En el articulillo coñero, Stroustrup mencionaba un peso de 2.1MB
Si un camionero ve una página que habla sobre camiones seguramente no le llamarás friky, pero como son "cosas de ordenadores" entonces sí.
Es hasta cómico.
"Nuestras máquinas eran ágiles y fuertes. Hoy en día se abusa de la incorporación de memoria a causa de las exigencias de software pero es algo completamente inútil: hay que esperar a que los malditos arranquen, que inicien, que carguen programas residentes, ¡Es un caos absoluto!"
www.fayerwayer.com/2010/03/sinclair-zx80-la-revolucionaria-computadora
Donde esté el código máquina que se quite la POO.
La abstracción está bien para maximizar los beneficios: no requiere formación especializada.
Para sacarle el jugo a una máquina, hay que conocer su arquitectura. Y eso requiere personal especializado. Sólo así se consiguen sistemas 99.9% failsafe (por eso ahora no lo es ninguno).
¿¿¿A prueba de fallos con ensamblador??? Me lo explique.
El problema es que quién se ha peleado con lenguajes de 'bajo nivel' y va usando los de 'alto', máquinas virtuales o frameworks... sabe que éstos por debajo están hechos sobre los de niveles inferiores e intuye como estarán organizados y por tanto puede minimizar el impacto de uso de recursos, errores, etc... junto con los conocimientos teóricos que haya podido aprender, más de arquitectura que comentas.
Cuando alguién sin conocimientos teóricos y poca experiencia entra de lleno usando frameworks y demás es indudable que va a gastar muchísimos más recursos de la máquina donde ejecute su embolado, además del triple de errores.
Entender la POO, no ya a un nivel alto sino básico, tampoco es sólo menester de gente no especializada. Me remito a lo que he dicho en los párrafos anteriores.
#28 Con el C se puede programar ajustando bastante al hardware, teniendo en cuenta el tamaño de la caché para algunos algoritmos y cosas así, además de poder insertar de forma nativa código ensamblador.
Puedes programar normal todo el programa y en una segunda vuelta buscando eficiencia pasar algún algoritmo pesado a ensamblador si es un algoritmo fácil claro
C++ conquista el mundo muhahahah.
-Si trabajas con una MV te ahorras tener que conocer el hardware al detalle. Más bien necesitas saber de algoritmia para saber optimizar.
-Si las aplicaciones hoy día fallan más que antes es porque son mucho más complejas y hay muchas más. Y son más complejas porque tenemos herramientas que nos permiten crear aplicaciones complejas en relativamente poco tiempo. Por ejemplo, yo hice un Tetris en la universidad, usando Modula-2 y luego lo hice en ensamblador. En un lenguaje "normal" lo tienes hecho en un par de días, en ensamblador tardas semanas. No hay control de memoria, ni de que te salgas de array con el índice... etc, con lo que escribes un montón de código que cuesta mucho mantener y no es menos propenso a fallos (en cuanto tienes miles de líneas es más bien lo contrario.
- La calidad en general de las aplicaciones ha bajado en algunos aspectos, pero es que cualquiera ahora programa. Un buen programador te hará un código robusto en cualquier lenguaje, y si usa un lenguaje sencillo lo hará además en menos tiempo.
#31 De eso creo que nos podemos olvidar: Linus ha dicho que C++ está bien para hacer aplicaciones, pero para el kernel le parece una pésima idea (yo te lo digo así, de un modo suave. Imagina como respodió él a la sugerencia, con su historial de troll en los foros
#20 Un buen compilador tiene todo eso en cuenta y puede optimizar más que nadie "a mano" hoy día.
Un buen compilador tiene todo eso en cuenta y puede optimizar más que nadie "a mano" hoy día.
Hay cosas que el compilador no puede hacer por muy bueno que sea y por ello se continúan haciendo a mano, un ejemplo lo tienes en el encoder x264 con partes esenciales escritas directamente en ensamblador.
Y los compiladores muchas veces se pasan de listos y la arman optimizando. Me ha pasado varias veces ya.
Y luego la velocidad de ejecución de un mismo código intensivo en CPU compilado en C y en C++ son bastante diferentes.
¿Trabajas?¿En qué? Ya me parece gili algo muy común en españa como que alguien que solo trabaja con php denoste java o este .net o este C+ o este yo que sé como para que encima alguien que supongo trabajará con sistemas en tiempo real o algún tipo de sistema embebido denoste..... LA POO Y LA ABSTRACCIÓN.
Y sí. Lo de conocer las plataformas al detalle obviamente se aplica con sistemas empotrados... Como para conocer a fondo el hardware de cada tarjeta gráfica por poner un ejemplo.
Del Java y el .Net también se hace un mal uso. Y del flash. Y de la web en general...
Querer convertir el navegador en plataforma multi-purpose is a no-no. Y eso que no está saliendo del todo mal...
Definitivamente, me gustaba más la filosofía Sinclair.
Y con esto aún mucho más:
www.dailymail.co.uk/femail/article-1195788/Beauty-boffin-Why-young-lap
Tipo listo, sí señor...
En resumen meneame.net es una web de frikis del ordenador que adoran al PSOE.
thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
Yo no comparto parte de sus opiniones, pero como soy "javero", supongo que es normal: para mí la POO significa comodidad y una forma de acercarse a los problemas intuitiva, aunque el problema de Java es el mismo que el de C++ o PHP: hay tanta gente que dice que es programador porque ha hecho un curso de 3 meses en el INEM o alguna academia que para encontrarte código decente tienes buscar mucho.
Obviamente no se me ocurriría hacer en Java un SO, pero un compilador sí se puede hacer en Java. De hecho algunos pinitos he hecho, con JFlex. Obviamente es más lento que un compilador en C o C++, pero realmente el tema de velocidad en ciertos casos es indiferente: un compilador en Java en un PC hoy día tardará bastante menos en compilar una aplicación que un compilador equivalente en C en un PC de hace 2 años.
La verdad es que hay que saber cuando hay que usar la navaja (programar C), y cuando la granada (programar en C++), por que si usas C++ solo por que es orientado a objectos y el proyecto es suficientemente pequeño para hacerlo en C, probablemente la granada te acabe explotando en las manos.
En cualquier caso yo recomiendo usar una AK47 ...quería decir usar python, y como mucho realizar en C / C++ las partes que necesites mucho rendimiento (accediendo a esas partes desde código python atraves de wrappers)