ISO actualiza las especificaciones del lenguaje C. Ya tenemos la nueva versión "C11"

La ISO ha actualizado el estándar para el lenguaje C de programación. La nueva versión de la especificación se denomina ISO/IEC 9899:2011 (aunque también es conocida informalmente como C11), amplía la compatibilidad con C++ y añade nueva funciones (multi-threading, mejora de soporte Unicode, ...). Más info: http://en.wikipedia.org/wiki/C1X

[#1 faceb00k]

En verano se actualizó C++
ISO aprueba por unanimidad C++0X: ¡ya tenemos el nuevo estándar C++11!

ISO aprueba por unanimidad C++0X: ¡ya tenemos el n...

[#3 Tao-Pai-Pai]

Python is for boys. C is for men.

[#7 oxelo]

#3 Maybe in 1991, now Python is for men, C for cebolleta-grandpas.

[#12 oxelo]

#7 Un minuto de silencio por el sentido del humor de los que votaron negativo este comentario.

[#20 Desactivado]

#12 La ironía no se ve en internet.

[#13 chachechichochu]

#7 Python es el nuevo Basic. ¿Compararlo con C? jajajaja

[#15 centelleante]

#13 perdona, pero el nuevo basic es PHP.

[#22 chachechichochu]

#15 Perdóname tu, pero si PHP es el nuevo Basic, Python es el Pascal de nuestros tiempos. En su tiempo molaba, era mejor que C y todos los lenguajes juntos, pero ahora quien lo usa?

[#24 centelleante]

#22 wtf? o estás hilando muy fina la ironía, o vives en un mundo paralelo

[#14 randomstirrer]

El stdnoreturn es, sinceramente, trascendental: #define noreturn _Noreturn .

#7 Yo ya solamente programo en Python. Cuando necesito velocidad, traduzco alguna función o clase a C/C++ o Fortran, pero eso ya no lo considero programar, sino traducir

[#16 Desactivado]

#3 Python mola. Y punto.

[#17 llou]

#3 C es para programar las partes críticas del código y python es para programar rápida y claramente el resto. Al menos es como programo yo.

[#2 Desactivado]

Anonymous structures and unions, useful when unions and structures are nested

¡Por fin! Ahora será más fácil hacer programación orientada a objetos en C clásico.

[#4 Desactivado]

#2 minipunto para el caballero. Ahora, resumiendo todo lo que nos meten aquí (borrador de este año en http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):

"Esta tercera edición cancela y reemplaza la segunda edición ISO/IEC 9899:1999, como corregida por ISO/IEC 9899:1999/Cor 1:2001, ISO/IEC 9899:1999/Cor 2:2004, y
ISO/IEC 9899:1999/Cor 3:2007. Los cambios más significativos desde la versión anterior incluyen:
— Características condicionales (opcionales, incluyendo aquellas que antes eran obligatorias)
— Soporte para múltiples hilos de ejecución, incluyendo un modelo de secuenciamiento de memoria mejorado, objetos atómicos y almacenamiento local (TLS), todo esto en stdatomic.h y
threads.h
— Macros características de coma flotante adicionales (float.h)
— Lectura y especificación de alineamiento de objetos (stdalign.h, stdlib.h)
— Caracteres y cadenas unicode (uchar.h)
— Expresiones para tipos genéricos.
— Aserciones estáticas.
— Structs y unions anónimas.
— Funciones que no devuelven el control.
— Macros para números complejos (complex.h)
— Soporte para acceso exclusivo a ficheros.
— Suprimida función gets.
— Añadidas las funciones aligned_alloc, at_quick_exit, y quick_exit en stdlib.h
— Soporte (opcional) para comprobación de límites de arrays.
— Soporte (opcional) para la analizabilidad del código."

He puesto en negrita lo que creo que son auténticas mejoras. El resto eran cosas ya inventadas en diversos sistemas (sobre todo Unix), pero que necesitaban una formalización en una ISO de una vez por todas.

[#5 Desactivado]

Buena noticia, aunque hay algún detalle que personalmente no me termina de gustar...
Suprimida función gets.
No veo mejora en eso. Creo que un usuario debería ser libre de usarlo, eso si, recibiendo un sonoro warning por parte del compilador. Para hacer cuatro experimentos tu mismo, no creo que sea necesario poner una función de "alta seguridad" en vez de un simple gets. Donde no hay que usarla, es cuando no es un experimento para ti mismo, sino un programa serio.

#2: Y sobretodo, que esas estructuras y uniones, ahora son legión, ni perdonan, ni olvidan.

[#36 Desactivado]

#5 ¿Cuál es el problema de gets? (Soy nuevo en ésto :P)

[#37 Desactivado]

#36: Teóricamente es insegura, porque rellena un vector con carácteres metidos por el usuario, y no mira los límites del vector, con lo que podría escribir más allá de su tamaño real y dar problemas.

Pero vamos, si estás haciendo unos ensayos en casa, no pasa nada por usarla.

[#38 Desactivado]

#36, puesto que #37 ya te lo ha dicho, sólo añadir que gets es una función tan nefasta (es virtualmente imposible utilizarla sin que tu programa se vuelva reventable) que el propio gcc te suelta una alerta diciendo que tener una sóla llamada a ella en todo el hilo de ejecución es sinónimo de gordísimo riesgo de seguridad.

[#39 Desactivado]

#38 #37 Gracias, suponía que sobrescribía memoria pero no sabía cómo controlarlo, pero para capturar texto con espacios resulta cómoda si el programa no es muy importante. Pensaba que habría alguna forma de usarla y limitar el número de carácteres pero ya veo que no. (Con scanf al principio no sabía cómo evitar problemas como que al programa se le vaya la olla al meter un carácter o meter varias entradas de golpe y al luego descubrí fflush()). ¿Cuál sería la mejor opción?

[#40 Desactivado]

#39, lo primero es no usar scanf para leer del teclado. Lo correcto es leer línea a línea con fgets y luego procesarla con sscanf (si fuere necesario).

Y contra gets, igualmente fgets es la mejor opción: necesitas pasarle el buffer, su tamaño y de dónde lo vas a leer (normalmente stdin). Y listo. Ahora ojo, recuerda que fgets te va a dejar el \n al final de la cadena, por lo que quizá te interese borrarlo.

[#41 Desactivado]

#40: Pues eso, que para un programa sin importancia (por ejemplo, un programilla que me haya hecho para calcular alguna probabilidad o generar algún diccionario), gets es suficiente.

[#43 Desactivado]

#41, yo soy muy maniático con esas cosas, mejor evitarlas siempre, pero a ver, que sí, que no te van a meter un exploit en un holamundo.

#42, porque hay más usuarios bienintencionados que profesionales. No sabes cuántas veces he visto la guarrada del system("PAUSE") seguida religiosamente por una legión de adoradores de la programación por lotes del MS-DOS. Y ya ves. Lo de los acentos sí que es la primera vez que lo oigo ¿a qué te refieres exactamente?

[#44 Desactivado]

#43: El system("PAUSE"); se enseña incluso en universidades.

[#45 Desactivado]

#43 Me refiero a que no ten enseñan a poner un triste acento. Yo busqué en Internet y no saqué nada en claro, pero de descubrí que poniendo la contrabarra seguida de el código de la letra en octal funcionaba ("\243" para la "ú", por ejemplo), aunque no entiendo por qué es tan enrevesado En cuanto al pause es un mensaje al sistema no? Mas allá de que no funcione en todos los SO no tiene ningún inconveniente no?

#44 Doy fe de ello.

[#46 Desactivado]

#45, a ver, eso es distinto. Yo en Linux escribo con acentos entre comillas y me sale por pantalla sin problemas. En tu caso, deduzco que estás escribiendo en C desde Windows programas de DOS, lo cual es muy pintoresco en los años que nos toca vivir (o quizá estés programando una aplicación de consola de Windows, de 32 bits). De cualquier modo, estás ante un problema de codificación, DOS tiene su propia codificación (página de códigos 850 si estás en España, 437 en EEUU) y Windows la suya (UTF-8, ISO-8859-15, ISO-8859-1, la que sea). Cuando metes acentos, las cosas no coinciden y sale basura. Pero eso no es problema de C, eso es problema de los editores que estás manejando.

Es tan enrevesado porque lo que estás haciendo no es estándar, es un mero hack al fin y al cabo. No sé qué editor estás usando, pero aún así, hay un programa por ahí (no sé si los hay en Windows, es muy probable que sí) llamado iconv dedicado a convertir codificaciones, quizá te interese hacerle eso a tus archivos antes de compilarlos. Incluso hay bibliotecas de C para convertir codificaciones, pero eso ya no sé si te será demasiado lío.

[#48 Desactivado]

#46 Hablo de la consola típica, en aplicaciones con GUI nunca he tenido ese problema. En cuanto al editor, uso el DevCPP, auque antes usaba el visual express y pasaba lo mismo. Alguna vez he mirado para cambiar la codificación pero sin éxito. En cualquier caso no es sólo cosa mía, muchas veces he visto aplicaciones en consola sin acentos o sources con caracteres raros que al final se veían como acentos o caracteres especiales.

Lo de usar bibliotecas me parece más engorroso que lío, llevo poco en esto de programar y ya he trasteado con las api de Windows y OpenGl En cualquier caso el cambio tendría que hacerlo desde las propiedades del proyecto para que le compile al profesor, yo por mi cuenta ya hago poco en consola.

[#50 Desactivado]

#48, claro, porque ya les han cambiado la codificación para que al compilarlo te salga bien por la consola o la peña pasa directamente de meter acentos y se ahorran el curro de convertir.

La consola de Windows debería rehacerse. Su planteamiento es bastante miserable por culpa de la retrocompatibilidad que hoy por hoy no tiene ningún sentido. Pero qué pasa, han estado arrastrando eso desde que existe el Windows 3.11, y Microsoft es una empresa especialmente melancólica con un terror absoluto a eliminar software legacy de sus productos. Así no se puede tener un sistema con un mínimo de coherencia, jolín.

#49, pulsando Enter basta. Qué más da, si estás en DOS y puedes incluir puedes usar getch() en su lugar. Esta sí que devuelve a la primera pulsación.

[#51 Desactivado]

#50: No estoy de acuerdo. La retrocompatibilidad es FUNDAMENTAL.

Hay muchos programas cuyos autores no les van a actualizar, y si la nueva versión de Windows no permite usarlos, la gente no podrá actualizar Windows. Quizás en ámbitos de electrónica, informática y demás esto que digo no tenga mucha importancia, pero es que la informática hoy en día va mucho más allá de las telecomunicaciones y la electrónica, hay muchos procesos industriales o programas de aprendizaje para otros ámbitos que dependen mucho de la consola.

Te podría dar por ejemplo el programa de elasticidad y resistencia de materiales 1.

Si MS mete una actualización de la consola que rompe la compatibilidad con el programa, los profesores no podrán actualizar el sistema operativo, o bien, tendrán que renunciar a usar ese programa, y es muy posible que no exista otro programa que haga EXÁCTAMENTE lo mismo.

[#52 Desactivado]

#48 Yo el getchar() lo conozco pero no me gusta, eso de pedir algo que no voy a usar me resulta molesto, si lo que quiero es una pausa y el programa es pera Windows pongo la pausa y listo, en cuanto al rendimiento me da igual, es una pausa , poco me importa que tarde 1 o 2 milisegundos Aunque soy consciente de que no es buena idea si pretendo portar el programa. También uso el "cls". Pero vamos, si programase en linux ya me miraría sus características (no se si permite más carácteres por línea por ejemplo, en windows son siempre 80).

PD: Estoy con #51, un SO como Windows tiene que mantener la retrocompatibilidad, para otras cosas está linux y la imaginación, yo no veo el problema.

[#53 Desactivado]

#51, ¿y realmente eso justifica tener que cargar con software viejuno en cada nueva versión del Windows? Yo creo que tener tu propia capa/entorno/programa de retrocompatibilidad separada del SO basta. A mí lo que me preocupa de todo esto no es la retrocompatibilidad necesaria con cosas que ya existían en las versiones viejas, mi problema está con software nuevo que utiliza lo viejo.

Por ejemplo, en Windows eso pudo hacerse pero no entiendo muy bien por qué no. En Windows hay esencialmente dos tipos de aplicaciones que funcionan en consola: las aplicaciones CLI de Windows y los programas de DOS. No tengo nada contra lo segundo, pero ¿realmente es necesario que las aplicaciones CLI de Windows tengan que funcionar con la página de códigos 850, sólo por mantener la coherencia con la emulación de los programas de DOS? Ahora que el DOS ha desaparecido forzosamente en las CPUs de 64 bits, ¿de veras tendrá sentido cargar con esto? Al final quedará como algo anecdótico y motivo de varios quebraderos de cabeza para los futuros programadores, que se preguntarán, "¿qué tiene de especial la consola? ¡si es sólo un ventanuco con letras!"

#52, y Linux la mantiene, hasta cierto punto. Llegados ahí, eso no se usa más. Las bibliotecas de 32 bits en /usr/lib32 están condenadas desaparecer cuando las CPUs dejen de emularlas, los binarios paginados de Linux (por ejemplo) ya no se reconocen más. Esto en parte es bueno porque obliga a los programadores a mejorar su software. Pero es que no puedes detener distorsionar el avance de un SO sólo porque los programas de hace 15 años dejen de funcionar, cuando las nuevas versiones deberían estar usando las interfaces de hace 5.

[#54 Desactivado]

#53: "¿qué tiene de especial la consola? ¡si es sólo un ventanuco con letras!"

¿Y cómo aprendes a programar si no es con consola? A parte de que para hacer una aplicación ultrasencilla, quizás te venga mejor usar la consola que andar con ventanas.

Y en los programas antiguos, yo creo que lo mejor es asegurarse de que funcionen bien. Uno de los principales problemas de Linux y su entorno es la poca retrocompatibilidad. No todos los desarrolladores están dispuestos a andar recompilando sus programas a cada versión nueva que sale, ni tampoco muchos usuarios están dispuestos a hacerlo ellos mismos in aunque les des el código fuente.

[#55 Desactivado]

#54, no me has entendido. Quiero decir, ¿por qué la consola tiene que tener la codificación de DOS y no la de Windows? ¿Por qué tiene que ser especial? ¡Es una ventana como las demás! Esto es uno de los problemas de la retrocompatibilidad, incoherencias en la interfaz.

Y sobre lo que comentas de Linux, eso no es un problema del sistema operativo, es del software. El software requiere un mantenimiento, aunque sea simplemente recompilarlo o actualizar las llamadas. Y cuando no se hace ni esto, es que el proyecto está abandonado (casi siempre por una alternativa mejor). Que tengas tu programa sin actualizar durante un par de añitos tiene un pase, pero que lo tengas abandonado hasta el punto que tenga que utilizar bibliotecas obsoletas... macho, es que eso no te lo hace ningún desarrollador o grupo de desarrolladores serio, ni en Windows, ni en Linux, ni en Mac. No puedes ofrecer un producto de hace muchos años (sobre todo en el mercado de los ordenadores) como una solución a nada. No ya por su calidad, si no porque las formas de hacer las cosas cambian.

[#56 Desactivado]

#55: Ah, vale, ya te he entendido. Quizás la solución es que en el menú de la ventana, tengas una opción que te permita cambiar la codificación.

Y sobre lo que comentas de Linux, eso no es un problema del sistema operativo, es del software. El software requiere un mantenimiento, aunque sea simplemente recompilarlo o actualizar las llamadas. Y cuando no se hace ni esto, es que el proyecto está abandonado (casi siempre por una alternativa mejor).

El tema está en que muchos programas de Windows, sin ese mantenimiento, siguen funcionando, y además, no siempre hay una alternativa mejor.

Que tengas tu programa sin actualizar durante un par de añitos tiene un pase, pero que lo tengas abandonado hasta el punto que tenga que utilizar bibliotecas obsoletas... macho, es que eso no te lo hace ningún desarrollador o grupo de desarrolladores serio, ni en Windows, ni en Linux, ni en Mac.

Es que no siempre hay desarrollador. Por ejemplo, en mi carrera usamos una vez un programa de cálculo de vigas que iba por "GUI de consola", y es lo que hay. Se usa un programa que fue un proyecto de fin de carrera adaptado a lo que querían los profesores. Actualmente no se hacen proyectos de fin de carrera que permitan actualizarlo (a saber dónde anda el código fuente).

Por supuesto, es para calcular vigas simples, es decir, el CYPE no vale, porque es demasiado complejo (y caro) para hacer una pequeña práctica para adentrarse en el cálculo de estructuras.

En otros casos, se trata de programas libres, con código fuente abierto... pero cuyos desarrolladores han dejado de desarrollarlos y no van a tocar nada más. Y es que si nadie quiere se pone manos a la obra, no se puede. Y es que no es tan fácil como creemos, toquetear un código fuente no es nada fácil, no basta con saber escribir un "hola mundo" en C.

No puedes ofrecer un producto de hace muchos años (sobre todo en el mercado de los ordenadores) como una solución a nada. No ya por su calidad, si no porque las formas de hacer las cosas cambian.

Pero es que es lo de antes, muchas veces tienes el programa ahí y es lo que hay.

Incluso Windows no es perfecto, los programas CNCtorno y CNCfresa que se usaban para hacer las prácticas de Tecnología mecánica no funcionaban bajo Windows XP. Hablo de programas de hace unos 20 años que iban para consola (quizás programados con conio.h o algo similar). En clase usabamos una versión para Windows que si era compatible con XP, pero lo que y tenía copiado en casa eran los anteriores. Me hubiera gustado haber podido trabajar un poco en casa, pero no pude. Pero bueno, al menos aprobé.

Pero el tema que digo, es ese, que la retrocompatibilidad muchas veces es algo muy necesario y que no lo elije el usuario ni nadie, es algo que sucede por diversas circunstancias.

[#47 Desactivado]

#45, ah, y el problema de PAUSE es el siguiente: tú cuando haces una aplicación de consola en C para Windows, estas tienen la maldita manía de cerrarse solas cuando acaban. Esta locura es bien conocida por los veteranos usuarios de DOS que vienen a Windows, y arreglan temporalmente este problema añadiendo un PAUSE al final de sus enternecedores archivos .BAT -lo cual es un remedio más que aceptable teniendo en cuenta las limitaciones de este tipo de archivo-

Pues no sé por qué, pero parece que algún ex-programador de archivos .BAT aprendió a chapurrear un poco en C e introdujo la guarrada del system("PAUSE") porque le parecía lo más normal. Lo más seguro es que le hubiesen enseñado la función system antes que la función getchar(), la cual hace lo mismo que system ("PAUSE") pero siendo portable y más rápido.

¿Qué hace system ("PAUSE")? Bifurca (o salva, si estás en DOS) el proceso, llama al comando PAUSE, el sistema lo ejecuta, PAUSE muestra el mensaje por pantalla, espera y vuelve para terminar. Sólo funciona en DOS/Windows.

¿Qué hace getchar()? Lee una tecla -aunque quizá necesites pulsar ENTER para que devuelva el control-. Funciona en todos los sistemas.

Juzga por ti mismo. En tu sistema, vale, da igual. Pero es muy feo, lento y engorroso.

[#49 Desactivado]

#47: El problema es que getchar necesita que pulses dos teclas.

[#42 Desactivado]

#40 Gracias, algo así?

fgets(nombre, L_NOMBRE, stdin);

No se por qué demonios se empeñan en todos los sitios en enseñar funciones que fallan si o si... Entre eso y que pasan de los acentos, etc... Luego hay que aprenderlo todo por cuenta propia.

[#6 Desactivado]

#2 otro que se piensa que la programación orientada a objetos se puede hacer con structs que contienen punteros a funciones.

Cada lenguaje es bueno para lo que es bueno. C es bueno para lo que es bueno. Pero por muy bueno que sea C, no sirve para hacer programación orientada a objetos. Hacer un struct y llamarlo Object no es suficiente.

[#8 LesPaul]

#6 +1

Si quieres usar programación orientada a objetos con las ventajas que te proporciona un lenguaje de bajo nivel como C, puedes usar C++. La pega que tiene es que añade algo de complejidad. Otra alternativa sería Objective-C, pero la sintaxis tiene la influencia de Smalltalk.

Desde luego un lenguaje como C que está orientado únicamente a la programación estructurada, no se puede utilizar para programar en objetos. Son mundos distintos, y al mezclar uno con otro, estás mezclando los inconvenientes de ambos. Es como intentar programar en Java mezclando ideas provenientes de la programación estructurada (lo que hace muchísima gente realmente)

[#21 Desactivado]

#6 #8 Indudablemente: pero no siempre necesitas meter punteros a funciones en una estructura para "simular" objetos, sólo si quieres hacer métodos virtuales. Para todo lo demás, no lo necesitas.

No niego que hay características avanzadas de la POO que son complejas de hacer "a pelo", pero si hablamos exculsivamente de las características básicas, comunes a todos los lenguajes orientados a objeto, sí se puede hacer perfectamente con estructuras; incluso la herencia, aunque obviamente si se dispone de estructuras anónimas es mucho más sencillo.

[#25 Desactivado]

#21 creo que confundes "POO" con "estructuras de datos complejas".

La programación orientada a objetos se fundamenta en tres pilares: herencia, encapsulación y polimorfismo. Dichas características han de ser soportadas por el lenguaje tanto en tiempo de compilación como de ejecución, y C no las soporta.

Así que decir que "uso lo básico de POO" cuando lo que quieres decir es "uso structs", es un error de concepto.

[#26 Desactivado]

#6 #8 #25 gobject proporciona herencia, encapsulación y polimorfismo. Que es un dolor programar OO en C, pues sí, pero se puede. De hecho los primeros compiladores de c++ traducían el programa a c y luego lo compilaban.

[#27 Desactivado]

#26 según tu razonamiento, el lenguaje máquina es a la vez programación estructurada, programación funcional, programación orientada a objetos, programación orientada a aspectos, una máquina virtual de Java, las macros de Excel, Javascript y el scripting engine del Metal Gear 4... porque todos ellos acaban traduciéndose a lenguaje máquina.

[#28 Desactivado]

#27 Para programar OO en cualquier lenguaje:

1) Construir un compilador de un lenguaje OO en ese lenguaje.
2) Enjoy.

[#30 Desactivado]

#28 fuck yeah!
#29 ni tu conocimiento de la programación.

[#31 Desactivado]

#30 te voy a resumir tu razonamiento:
Si A entonces C
Si B entonces C
De donde tu deduces que C es A y B a la vez.
Con razonamientos así no creo que programes muy bien

[#32 iampiti]

#31 ¿Te has fijado en su nick? No le respondas...
De todas formas, es bastante obvio que todo acaba por transformarse a código máquina. La programación estructurada, orientada a objetos, funcional, etc. son distintos enfoques que hemos inventado para decirle a la máquina lo que tiene que hacer. Unos son más apropiados que otros para ciertas cosas.
Sobre la noticia: No soy un experto en C pero parece que lo que han hecho es añadir unas pocas mejoras útiles sin cambiar demasiado el lenguaje; o sea, lo que tenían que hacer. A estas alturas no se puede pretender transformar C en algo mucho más complejo o diferente, para eso ya tenemos otros lenguajes

[#29 Desactivado]

#27 Tu capacidad de razonamiento no es muy buena.

[#34 Desactivado]

#27 Pues yo creo que tiene toda la razón: la programación orientada a objetos es una METODOLOGÍA, o sea, una forma de hacer las cosas. Si el lenguage te lo facilita, es más sencillo de trabajar de esa manera; si no, será más complicado o directamente un suplicio, pero lo importante es la manera en que trabajas.

[#35 Desactivado]

¿Cuándo la gente dejará de confundir paradigma con lenguaje? La programación a objetos está por encima de cualquier lenguaje en el que se pueda utilizar, y C es uno de ellos. GTK+ (y en concreto gobject como dice #26) es un ejemplo de paradigma de programación orientada a objetos.

Ahora, ¿que la gente siga queriendo usar las fantasías sintácticas de otros lenguajes porque le resulta un lío pensar en lo que el programa está realmente haciendo? Muy bien, pero eso ya es otra historia.

[#23 Desactivado]

#6 #8 Tampoco me interpreteis mal: obviamente jamás se me ocurriría hacer un proyecto grande orientado a objetos en C; pero para pequeños proyectos en los que no apetece meterse con C++ sí es útil poder aplicar algunas bases de POO, y todo lo que lo simplifique se agradece.

Por cierto: el modelo de objetos de Objective-C mola

[#9 EsKaRFeiS]

web development in C is for chuck norris

[#18 Desactivado]

#9 ¿Te refieres a hacer un CGI (Common Getaway Interface) en C?
Porque yo lo he hecho.
Pero solo una vez enseguida me pasé al asp y luego al php.

[#19 Desactivado]

Teniendo en cuenta la enorme lista de incorporaciones que hubo con C++11, esta se me antoja un poco pequeña; estoy seguro que podrían haber metido muchas más, como los default struct values, o que también incorporase el nullptr de C++ para no andar con problemas de portabilidad.

Pero bueno, aveces estos cambios aparentan poca cosa, pero luego dan lugar a cambios más radicales de lo que se pensaba al principio; ejemplo fueron los templates. Como me diejeron una vez, el C no fue diseñado para ser un lenguaje de programación sencillo, sino para exprimirle potencia a un ecosistema amplio de procesadores.

[#11 Desactivado]

Relacionada: Homenaje a Ritchie (Write in C)

Homenaje a Ritchie (Write in C)

[#10 Desactivado]

Y tendremos muchos meneantes que voten esto sin tener ni puta idea de que va la notícia. Con que hable de programación y esté en inglés pues a votar, tendría más votos seguro si se metiese la palabra linux o sofware libre.

[#33 Desactivado]

Donde esté el Java, que se quite todo lo demás...
(Es un chiste navideño, por si no lo habéis cogido).