#27 No se, para mi hoy en día prescindir de la orientación a objetos, la metaprogramación y todo lo que proporciona la STL no tiene mucho sentido. No ganas nada a cambio.

Hacer piruetas en C para conseguir funcionalidades que son nativas en C++ o están en la STL es una tontería, en mi opinión.

#31 "No ganas nada a cambio". -> Rendimiento.

Lo de las piruetas sí te doy la razón.

#40 Realmente, es un bulo que C++ sea mas lento que C. Depende mucho de como uses el lenguaje que del lenguaje en si, opr ejemplo cuando abusas de streams, y hay alternativas para no hacerlo.

En mi opinión, a no ser que no tengas un compilador de C++ en la plataforma donde vas a programar, o haya reestricciones de otro tipo (C/ADA para software critic), no tiene mucho sentido.

#49 +1

es un mito muy extendido por algunos ignorantes, que C++ es más lento que C. Luego lo justifican con ideas peregrinas como las llamadas mediante puntero (virtual), los destructores, etc.

C++ es "you pay for what you get". Si tu diseño necesita funciones virtual, también se necesitará algo equivalente en C. Resultado: Tu implementación nunca va a ser más rápida y correcta que la de C++, como mucho igualarás.

Si tu diseño necesita destructores, en C también deberás hacer algo parecido (liberar un recurso). Resultado: Tu implementación nunca será más segura que la de C++, porque tú te puedes olvidar de liberar el recurso, C++ no se olvida nunca.

En general lo que hace lento a C++ es el diseño sobrecargado e innecesario que te enseñan en la universidad, con clases, herencia y polimorfismo para todo.

#76 Bueno, x264 (el encoder más optimizado para h264 y diría que el más optimizado en general) utiliza C porque tiene una traducción más optimizada a ASM. Las partes críticas son en ASM. Y la gente que lo programó sabe muchísimo más que todos nosotros juntos, algo de razón habrá.

#82 Eso es un argumento muy pasado. Igual que h264, o el kernel de linux, utilizan C, hay otros proyectos muy críticos que utilizan C++ sin problema.

Repito, en C++ puedes hacer código igual de prestacional que en C. Lo que sí te reconozco es que C++ te va a obligar a "pensar demasiado" en algunos casos para asegurarte de que no añades overhead.

#76 Y si a eso le sumas que muchisima gente sigue usando C++ como si fuera C con clases, apaga y vamonos. Cada vez que veo un malloc o un memcpy en C++ me llevan los siete males.

#49 #49 Realmente, es un bulo que C++ sea mas lento que C.

No es un bulo. De hecho, es irremediable. Cualquier nivel de abstracción superior siempre va a suponer una pérdida de rendimiento respecto al anterior. Es el precio a pagar por la abstracción: generalizar siempre supone una pérdida de posibilidades en los ámbitos concretos.

Lo que sí sucede es que todo depende de las capacidades del programador. Un programador bueno puede hacer código en C++ que rinda mucho mejor que un código en C mediocre. Sin embargo, optimizando una misma solución al máximo, las características de C++ suponen un coste que puede no ser asumible. Por ponerte un ejemplo, hay muchos sistemas de trading de alta frecuencia que están implementados íntegramente en C a día de hoy, o en C++ sin usar muchas características propias del lenguaje. También he visto sistemas de balanceo de carga en servidores con partes escritas en ensamblador.

Los costes del alto nivel son despreciables en la mayoría de aplicaciones, o son asumibles comparados con otros costes (tiempo de desarrollo y/o portabilidad). Pero existen, están ahí y, dependiendo del contexto, se vuelven inasumibles.

#31 Te voto positivo sólo porque estoy harto de los haters de C++ que están por doquier (no me refiero al usuario con el que hablas, sino en general). Veo que tú le profesas el respeto que se merece.

#13 Y cual es la ventaja de C con respect a C++? A mi no se me ocurre ninguna situación donde sea major usar C que C++ salvo en casos de software empotrado muy especifico.

#21 Personalmente para mi eso ya es una preferencia personal. De todos modos depende del conjunto de caracteristicas que uses de C++ las tienes disponibles en C (nativamente o usando librerías) como por ejemplo orientación a objetos, herencia, interfaces, señales…

Pero lo dicho: para mi, según gustos.

#27 No se, para mi hoy en día prescindir de la orientación a objetos, la metaprogramación y todo lo que proporciona la STL no tiene mucho sentido. No ganas nada a cambio.

Hacer piruetas en C para conseguir funcionalidades que son nativas en C++ o están en la STL es una tontería, en mi opinión.

#31 "No ganas nada a cambio". -> Rendimiento.

Lo de las piruetas sí te doy la razón.

#40 Realmente, es un bulo que C++ sea mas lento que C. Depende mucho de como uses el lenguaje que del lenguaje en si, opr ejemplo cuando abusas de streams, y hay alternativas para no hacerlo.

En mi opinión, a no ser que no tengas un compilador de C++ en la plataforma donde vas a programar, o haya reestricciones de otro tipo (C/ADA para software critic), no tiene mucho sentido.

#31 Te voto positivo sólo porque estoy harto de los haters de C++ que están por doquier (no me refiero al usuario con el que hablas, sino en general). Veo que tú le profesas el respeto que se merece.

#21 Dependiendo del uso, C puede producir ejecutables mucho más chicos y mucho más rápidos que C++. Claro que hoy en día la solución para la lentitud de los programas es comprar un ordenador nuevo más potente.

#43 Realmente en el único caso donde necesitas ejecutables realmente pequeños en el caso de los sistemas empotrados, donde tiene sentido usar C (que no deja de ser un esamblador portable). Ahí si que te doy la razón, si es que realmente existe una limitación sería a nivel de ROM.

#59 El problema con eso (aclaro que soy programador con 30 años de experiencia) es que uno se acostumbra a "la vida fácil" y deja de preocuparse por optimizar, por el tamaño de los programas, etc.

Entonces resulta que ahora tenemos en el bolsillo ordenadores 100 veces más potentes que un PC de hace unas décadas y aún así nos parecen lentos. Yo me acuerdo cómo ejecutábamos el viejo Doom (gráficos 3D) de manera completamente fluida con un procesador de 66Mhz, 4Mb de RAM y 100Mb de disco (sin placa 3D obviamente). Claro que no eran los mejores gráficos del mundo pero con un procesador así se podía realizar todo el trabajo que hoy en día nadie se plantea hacer sin una placa 3D.

Si se hubiera mantenido la costumbre de optimizar al máximo el software, tal vez hoy en día la batería de los teléfonos nos duraría semanas en lugar de días.

#75 Bueno, es un trade off como siempre. Facilidad (velocidad y sencillez) vs Performance. Abstracción vs Performance. Etc.
Si las IT han llegado donde han llegado ha sido en gran parte porque la barrera de entrada se ha ido bajando cada vez mas gracias a todas las capas de abstracción y herramientas que se han creado. Desde luego que todo requeriria menos hardware si siguieramos escribiendo directamente en la memoria de video pero no habríamos llegado tan lejos (Realidad virtual, por ejemplo).

Con respect a los moviles, no creo que sea una comparación justa. La mayor parte del consumo se la lleva la pantalla. De todas formas estoy de acuerdo en que hay mucha mierda y mucho proceso en Segundo plano que se queda consumiendo ciclos. Pero esto es ma un problema de QA que de optimización, en mi opinión.

#75 El DOOM no era en 3D. Era un modo 7 de toda la vida con sprites 2D. Muy bien logrado, eso si.

#144 También te ayuda a entender eso trabajar en ensamblador y sigue siendo un coñazo. Confundís eso con que sea objetivamente malo o inútil o algo así. Trabajar a bajo nivel requiere más esfuerzo y por lo tanto puede resultar más tedioso, por ello existe C++, por ello existen frameworks, porque trabajar reinventando ruedas es un coñazo. No significa que sea malo.

#148 Ensamblador es un coñazo porque ni se parece al lenguaje humano. Pero a veces no hay otra. C es, en mi opinión, lo más cercano a ASM en cuanto a optimización de compiladores y herramientas "manuales" se refiere.

#144 En mi comentario #72 tienes un pequeño resumen de mi "no hay por donde cogerlo". Se puede ampliar, estoy abierto a debate.

#144 Por otra parte, las críticas de #13 y #2 donde “dejaron de leer” en cuanto se recomienda no programar en C
1°- he meneado esta noticia
2°- no he dejado de leer la noticia
3°- pregunto por qué afirma semejante cosa, cosa que no es de extranyar, no?

#144 Gracias por tu comentario. Lo de irrelevante muchas veces me saca de las casillas por gente que tumba noticias porque son de otra ciudad, o no saben del tema. Menéame es más que política.

Sobre la calidad del contenido del artículo, he de decir que coincido un poco con #16, he visto varias contradicciones en la misma sección del texto. El tema a mí me interesa mucho, pero si el autor hubiera pulido más su contenido no hubiera cometido imprecisiones.

Ni mucho menos pretendemos desmerecer tu intención.

#21 C esta implementado en todas las plataformas. hasta el chip mas mierdoso del mundo tiene un compilador de C, porque C es un lenguaje muy pequenyo. En cambio C++ es un lenguaje muy complicado (creeme, lo uso a diario). De hecho es bastante sencillo hacerte tu propio compilador de C, conforme a la especificacion completa del lenguaje... pero hacer un compilador del lenguaje C++ conforme a la especificacion completa de C++ es basicamente una locura.

#85 Si tienes razón, pero es obvio que si no tienes un compilador de C++ no vas a poder usarlo y tendrás que tirar de C, ahí no hay opción, no se trata de cual es major o peor

#21 Muchísimos gurús de la programación dicen que las abstracciones que ofrece C++ para lo único que valen es (no todos los dicen con estas palabras, pero el mensaje es básicamente ése) para que los malos programadores parezcan menos malos. Pointer chasing, mayor dificultad para optimizar el uso de caché, árboles de jerarquía (el famoso diamante de la muerte)... C es como tener el capó del coche abierto y todas las piezas desmontadas hasta el último tornillo. Yo era muy de C++ y aunque es lo que uso para programar con el tiempo me he dado cuenta de que tienen toda la razón.

#111 Es que no todos podemos ser gurús
No todo el mundo es capaz de pensar en terminos de C (o asm vaya) y ver el sistema perfectamente en sus cabezas. Los programadores average necesitamos abstacciones.
Tampoco hay que olvidar que esto es un negocio, mi empresa me paga por programar y ella gana dinero con lo que yo hago, no tiene que ser perfecto, tiene que ser optimo.

#124 No hay una definición universal de lo que es óptimo. ¿Significa legible? ¿Mantenible? ¿O eficiente? ¿O una mezcla de todo a la vez?

#146 Significa que haga mas o menos lo que dijiste que haría en el contrato y que esté en la fecha acordada para poder cobrar el proyecto

#21 Tu mismo lo has insinuado, es la eficiencia.

#13: Yo es que incluso he usado C como si fuera un guión (script).

Es decir, para hacer una figura paramétrica basada en matemáticas, usé un código fuente que tomaba los valores de entrada del propio código (en la inicialización), y el resultado lo escribía en un fichero.

Para probar diferentes formas en esa figura probé a cambiar los valores de la inicilización y los parámetros, compilando el código cada vez. Se que no será eficiente, pero me funcionó bien.

#35 Pero hombre, lee los parámetros de la línea de comandos.

#42: Demasiada complicación si quieres hacer algo rápido y sencillo y no andar escribiendo los comandos cada vez.

Me refiero a que tenía esto en el código:
float ancho = 30;
float largo = 50;
float alto = 40;

Para hacer algo sencillo, que no vas a distribuir por ahí, te sirve. Vas tocando los parámetros hasta que te gusta el resultado. Por eso me refiero a que C puede incluso usarse como lenguaje de guión y no como lenguaje compilado.

#68 Pero hombre, para cosas así creo que era más sencillo usar ShellScript (Bash).

#110: ¿Y si es un código que tiene que hacer muchas matemáticas y en C ya iba lentillo?

#13 Madre mía lo que hay que oir. c es un lenguaje con un problema terrible e INSALVABLE que no tienen otros lenguajes modernos, y es la gestión de la memoria. A nadie en su sano juicio se le ocurre hoy en día poner en manos del programador la alocación y dealocación de memoria, gestionar explícitamente estructuras de datos basadas en punteros, gestionar buffers, tener que prevenir y detectar explícitamente desbordamientos de memoria,... es una fuente constante de problemas de seguridad y disponibilidad de recursos, de depuración, de manteninibilidad... uff es que me dan escalofríos.

A cada día que pasa c es cada vez de más bajo nivel, y sus aplicaciones son cada vez más específicas y limitadas. Cuando necesitas usar c sabes muy bien que tienes que usar c. Si tienes la más mínima duda al respecto, no lo uses. Y mi trasfondo es de microcomputadores y para mi c es mi lenguaje nativo.

#13 Razonamiento simplista es el tuyo, que tachas toda crítica de "hater", y al que la hace de inexperto o de "tonto" que no puede asumir la complejidad. Quizás los que critican C son, precisamente, más expertos y capaces que tú, y por eso lo desaconsejan: porque lo entienden de verdad.

La razón número 1 por la que se desaconsejan lenguajes como C es por el ratio de errores. El 99% de los agujeros de seguridad son por buffer overflows, printf overflows, ROPs, etc. Eso con un lenguaje con gestión decente de memoria (o gestión, a secas, ya que C no tiene nada) no te puede pasar.

#5 A nadie le gusta Java.
#13 Todo lo que dices no es incompatible con que escribirlo sea un coñazo, lo cual es una visión subjetiva sobre la verbosidad o sobre cómo hay que escribir el código. Un lenguaje puede ser bueno, versátil, moderno y tener muchas librerías y, aún así, ser un coñazo para escribir.

#13 la supuesta falta de orientación a objetos de C

En el clavo. El día que se enteren de lo que es un puntero a función, les da un apechusque.

solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva

Aquí ya no estoy tan de acuerdo. Esa complejidad no es supuesta, sino real.

#c-2" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/2">#2 #13 A mí me encanta C, es el lenguaje con el que empecé a programar y todavía lo uso habitualmente (y lo prefiero personalmente a ese Frankenstein que es C++, que también me toca usar a menudo). Pero creo que el autor del post tiene toda la razón.

Por muchas librerías que le metas a C, sigue teniendo el problema de que es mucho más difícil de depurar que otros lenguajes de más alto nivel (Java, C#, Python, etc.) y además es inseguro, debido a la ausencia de chequeos automáticos que hacen que en cualquier programa un poco grande en C aparezcan posibles vulnerabilidades de buffer overflow y similares (esto lo corrigen alternativas como Rust, que combinan acceso al metal con seguridad opcional).

¿Cuándo hay que usar C entonces? Pues básicamente cuando necesitamos estar muy cerca de la máquina, como cuando programamos un driver, o desarrollamos para un sistema embebido. Vamos, lo mismito que dice el post: cuando no podemos evitarlo

#88 Me refería más bien a un nombre, una foto, un documento... no es que no me lo crea (y mas de algún diputado) pero no hay nada tangible en la noticia.

#21 ¿con las de ciencia solamente? Poco mmne lees tú

#24 No hombre, pero supongo que al ser un tema que me interesa especialmente me choca más. En el resto de notivias al menos ordenas por relevancia y te llevas uno o dos comentarios de provecho, aquí…

#21 Una pregunta. ¿Qué aporta tu mensaje? Lo que dices no es interesante -a nadie le importan tus lamentos-, ¿como es que no has aplicado tu norma de cerrar la boca?

#27 Aporta una crítica.

#21 Esto es un nido de trolled!!

En serio te crees que este es un sitio relevante de la web hispana? Jojojo.

Tómatelo menos en serio.

#21 Para temas de astrofisica ve a medios mas especificos como http://danielmarin.naukas.com/

#21 Es que por mucho que algunos lo vivan como algo épico e histórico, no hay mucho que rascar. Hay tan poca chicha en estas "noticias" que la gente no puede decir mucho más.

La noticia objetivamente es que después de la otra noticia (que se había iniciado el sobrevuelo a Plutón) la sonda mandó una señal, es decir, nada que no se esperase ni que no se haya repetido durante todo el tiempo de existencia de la sonda.

Estar entusiasmado por segunda vez por algo que tampoco es que tenga mucho más es difícil.

#53 Fabra...

#59

#10 Hombre, yo creo que el interés que tiene uno en asegurarse de que su propia comida no es tóxica es una buena garantía. Por lo demás, si estamos hablando de autoconsumo, el único afectado por una mala praxis en ese aspecto sería el propio responsable, así que tampoco es tan grave como una producción que vaya dirigida a millones de personas.