Portada
mis comunidades
otras secciones
#13:
#2 Es ahí donde he dejado de leer el artículo.
Hoy en dia ser hater de C (y practicamente de cualquier lenguaje compilado) es lo que está de moda. Gente que no ha programado nunca seriamente en estos lenguajes. En el caso de C yo creo que el mayor problema de esta gente es creer que todo se acaba en la librería estandard, la supuesta falta de orientación a objetos de C y la visión simplona del lenguaje que enseñan en los primeros cursos de las universidades, donde lo que prima es martirizar a los alumnos con la gestión de memoria. (#4)
C es un languaje bien provisto, flexible, portable, eficiente y actualizado, solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva. No estoy diciendo que esto justifique su uso en todos los casos, pero tacharlo de coñazo, complicado o "incomodo" es un razonamiento simplista.
Hoy en dia ser hater de C (y practicamente de cualquier lenguaje compilado) es lo que está de moda. Gente que no ha programado nunca seriamente en estos lenguajes. En el caso de C yo creo que el mayor problema de esta gente es creer que todo se acaba en la librería estandard, la supuesta falta de orientación a objetos de C y la visión simplona del lenguaje que enseñan en los primeros cursos de las universidades, donde lo que prima es martirizar a los alumnos con la gestión de memoria. (#4)
C es un languaje bien provisto, flexible, portable, eficiente y actualizado, solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva. No estoy diciendo que esto justifique su uso en todos los casos, pero tacharlo de coñazo, complicado o "incomodo" es un razonamiento simplista.
#126:
#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.
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.
#33:
#30 ¿cómo que foro de política?
Lo normal si algo no te interesa es que pases de ello... y llegará o no a portada.
No entiendo por qué si no te interesa la programación vas a negativizar (sin saber de programación y por tanto si es un buen artículo o no) un envío.
Si votamos irrelevante todo lo que no nos interesa personalmente nada llegará a portada.
Lo normal si algo no te interesa es que pases de ello... y llegará o no a portada.
No entiendo por qué si no te interesa la programación vas a negativizar (sin saber de programación y por tanto si es un buen artículo o no) un envío.
Si votamos irrelevante todo lo que no nos interesa personalmente nada llegará a portada.
#76:
#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.
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.
#72:
#58 Es que solo la primera recomendación ya es para tirarse de los pelos, lo más ridículo que he leido nunca.
"No usar char, int, short, long..." y sí usar uint8_t, uint32_t .. etc.
La del #pragma once, cuando no es estándar.
La de no utilizar memset, y luego reconocer que su alternativa no sirve debido al padding
La de utilizar arrays dinámicos en lugar de alojar memoria (como si el stack fuese infinito).
La de usar bool en lugar de devolver un valor especial (ptr == NULL), como si fuera una novedad gracias a stdbool
La de no usar malloc...
Pero bueno qué te puedes esperar del idiota que programó redis
"No usar char, int, short, long..." y sí usar uint8_t, uint32_t .. etc.
La del #pragma once, cuando no es estándar.
La de no utilizar memset, y luego reconocer que su alternativa no sirve debido al padding
La de utilizar arrays dinámicos en lugar de alojar memoria (como si el stack fuese infinito).
La de usar bool en lugar de devolver un valor especial (ptr == NULL), como si fuera una novedad gracias a stdbool
La de no usar malloc...
Pero bueno qué te puedes esperar del idiota que programó redis
#2:
La primera regla de C es no escribir en C si puedes evitarlo
y esto por qué?
y esto por qué?
#16:
Voto errónea porque el artículo y sus recomendaciones no hay por donde cogerlas. Ridículo
#12:
#c-9" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/9">#9 Sí, C estándar. Con él puedo programar en cualquier plataforma por limitada que sea con un rendimiento decente. C++ y C# no los he probado lo suficiente, pero es que C es un lenguaje más... funcional. 
#1:
¡Qué moderneces! Donde esté el Cobol de toda la vida
Comentarios
¡Qué moderneces! Donde esté el Cobol de toda la vida
La primera regla de C es no escribir en C si puedes evitarlo
y esto por qué?
Yo llevo como 20 años usando C, luego C++ y ahora C#, y hoy es el día que para hacer un "for", tengo que pararme un segundo a pensar cómo se hace.
#2 Porque es un coñazo.
#4 A mí no me lo parece. Es más, me gusta más que Java.
¡Sólo puedes aprender C si ya lo sabes!
#c-3" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/3">#3 ¿Sabes que dicen que lo del # del C# es porque es cuatro veces +?
Yo digo que al C# lo que es del C#.
Hasta hace 4 años en la ETSII de Valencia nos enseñaban C. Ignoro si se sigue enseñando pero apuesto a que sí.
#c-5" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/5">#5 seguro? el C estándar? no se habla ni de C++, ni de C#, ni nada parecido...
Yo ya sé C--
#8 En Sevilla enseñan Java en papel y boli.
Edito, en la ETSI si no recuerdo mal siguen enseñando C.
#c-9" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/9">#9 Sí, C estándar. Con él puedo programar en cualquier plataforma por limitada que sea con un rendimiento decente. C++ y C# no los he probado lo suficiente, pero es que C es un lenguaje más... funcional.
#2 Es ahí donde he dejado de leer el artículo.
Hoy en dia ser hater de C (y practicamente de cualquier lenguaje compilado) es lo que está de moda. Gente que no ha programado nunca seriamente en estos lenguajes. En el caso de C yo creo que el mayor problema de esta gente es creer que todo se acaba en la librería estandard, la supuesta falta de orientación a objetos de C y la visión simplona del lenguaje que enseñan en los primeros cursos de las universidades, donde lo que prima es martirizar a los alumnos con la gestión de memoria. (#4)
C es un languaje bien provisto, flexible, portable, eficiente y actualizado, solo que no todo el mundo puede asumir la, supuesta, complejidad que esto conlleva. No estoy diciendo que esto justifique su uso en todos los casos, pero tacharlo de coñazo, complicado o "incomodo" es un razonamiento simplista.
#11 en Valencia también es así y desde mi punto de vista así debe de seguir siendo.
#8 En Industriales de Valladolid aprendí C (2006), y hasta donde sé es el lenguaje que se sigue enseñando.
Y si, como dice #11, el 80% del examen era a papel y boli
Voto errónea porque el artículo y sus recomendaciones no hay por donde cogerlas. Ridículo
#14 No entiendo que utilidad tiene no aprender a usar un IDE aparte de sentirte mas macho.
#11 En Teleco en Sevilla se da C, ASM, Java y (en Telemática) un poco de C++ y Objective-C.
Glorioso artículo, gracias #0
Alucino con los que votan irrelevante al mejor envío de programación de lo que va de año.
#10 Malo malo...
#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.
C# powah!
Instead of:
long diff = (long)ptrOld - (long)ptrNew;
Use:
ptrdiff_t diff = (uintptr_t)ptrOld - (uintptr_t)ptrNew;
Hace lustros que hago nada en C (desde mi proyecto de final de carrera). Me alegro profundamente que hayan trabajado en liberar a C de tener que hacer pirulas para todo.
Ahora solo falta que hagan lo mismo para Javascript.
Yo con lo poco que he trabajado con C++ y Java he visto que son tremendamente parecidos, vamos que si aprendes a programar en C luego lo tienes realmente facil para saltar a Java.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/7">#7 ¿y le pusieron la # para no entrar en disputa con Citroen?
#8 Estoy en segundo, y en la mayoría de asignaturas trabajamos en Java. En LTP además hemos tocado Prolog y Haskell. Sólo hemos programado en C en FSO.
#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.
#11 En la politécnica de Huelva, hace 15 años se empezaba con Pascal y luego C.
#2: Porque hay gente que así se siente más guay.
Que cada uno escriba en el lenguaje que prefiera. A mi por ejemplo Python no me gusta por esto:
http://www.freecadweb.org/wiki/index.php?title=Dialog_creation/en#The_complete_script
Ahí tenéis un ejemplo de porqué Python no me gusta. En C (o en JavaScript) todo está estructurado con llaves , en Python no las hay. ¿Por qué? No lo se, pero yo ahí veo un código muy desligado, suelto...
Ojo, que JavaScript tiene sus pegas, como usar el + para "sumar" frases, es decir, juntar cadenas de texto. Si, parece bonito y cómodo al principio... hasta que tienes que convencer al motor de JavaScript que no quieres escribir "34", sino que sume lo que valen dos variables, siendo en ese caso la primera un 3 y la segunda un 4, y intentando conseguir un 7, no que te ponga un número detrás de otro.
#19 A mucha gente que no le interesa la informática ni la programación es normal que les resulte irrelevante. También es normal tratándose de un foro de política, donde a veces se envían cosas ajenas a la política que no siempre acaban cuajando.
#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.
#c-12" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/12">#12,#9 C++, sí está “emparentado” directamente con C.C# es una especie de java y compararlo con C/C++ es casi insultante…
#30 ¿cómo que foro de política?
Lo normal si algo no te interesa es que pases de ello... y llegará o no a portada.
No entiendo por qué si no te interesa la programación vas a negativizar (sin saber de programación y por tanto si es un buen artículo o no) un envío.
Si votamos irrelevante todo lo que no nos interesa personalmente nada llegará a portada.
#17 las clases en papel, las prácticas en PC, los exámenes en papel, los exámenes de prácticas en PC. 70% en papel 30% en IDE.
#26 tú estarás en la ETSInf no en la ETSII de la UPV . Java en industriales solo se toca en 4 en una asignatura para aplicaciones en dispositivos móviles .
#13: Yo es que incluso he usado C como si fuera un guión (script).
Se que no será eficiente, pero me funcionó bien.
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.
#29 Python/Javascript y C son lenguajes incomparables. Pertenecen a dos paradigmas diferentes. Yo por ejemplo no me siento comodo trabajando en un lenguaje que no sea fuertemente tipado. Ya me cuesta prescindir de la gestión de memoria en Java, pero si me quitas los tipos no soy nadie.
Las diferencias que comentas me parecen trivialidades. El identado de Python esta bien por que fuerza a los novatos a identar bien su código. La segúnda queja es un problema derivado de la falta de tipado y de la ambigüedad general de los operadores.
Hace relativamente poco, tuve que hacer un plugin npapi en C. Acostumbrado a funciones y tipado de alto nivel, volver a programar en C fue un puto infierno. Y meterle otras dlls o código fuente al proyecto daba para hacerse el harakiri.
#33 Eso de que "lo normal es pasar" es bastante discutible. Piensa que hay muchas familias con hijos que dependen del karma.
#34 Me has dado una guía no una razón para hacer un examen a papel eso sólo sirve para tener que aprenderte de memoria muchas cosas que tienes en la documentación del lenguaje.
#31 "No ganas nada a cambio". -> Rendimiento.
Lo de las piruetas sí te doy la razón.
#39 es que no quería darte una razón quería decirte que si que nos enseñan a usar el IDE, al menos una parte.
#35 Pero hombre, lee los parámetros de la línea de comandos.
#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.
#41 Si te he entendido. Lo que quiero es saber por qué dices que hay que aprender en papel.
Se puede programar una web en C: https://github.com/acanas/swad-core // autobombo
#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.
Como nadie lo ha puesto aún, ahí va:
#29 Pues yo lo veo perfectamente. El código no necesita llaves porque está bien indentado, que es una de las características de Python.
#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.
#8 El C sigue siendo un lenguaje útil, no para aplicaciones de tamaño grande, pero sí para rutinas de bajo nivel. Muchos dispositivos llevan rutinas en C
#5 Básicamente es porque a medida que el programa crece la posibilidad de que se te cuele un error de manejo de punteros o de memory leak y no lo localices nunca es muy alta. Java no tiene punteros pero además los beneficios de java no están tanto en el lenguaje si no en la máquina virtual.
#c-32" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/32">#32 insultante tampoco... pero no es comparable, es un lenguaje distinto... a mí, desde luego C# me gusta p.e. más que Java (con él sí que se puede comparar), aunque considero que está lejos de lenguajes más modernos como Ruby y Python.
Aprendí a programar en C (que no es lo mismo que saber C, que creo que realmente muy poca gente SABE) y doy gracias.
Gestión de memoria, programación a bajo nivel... hoy en día lo uso mucho en mi trabajo.
Y aunque las aplicaciones de escritorio las desarrollo en C# por rapidez, lo que aprendí en C lo uso cada día más en autómatas.
#29 Supuestamente las llaves dan la libertad de escribir como te de la gana. Si quieres puedes hacer un programa de una sola línea. Pero resulta que si no sigues algún standard después ni tu entiendes lo que has escrito, así que al final terminas utilizando la indentación para hacer más claro el programa con lo que las llaves dejan de tener utilidad. En python directamente usas la indentación y no necesitas las llaves.
#48: ¿Y si a mi me da la gana indentarlo de otra forma porque lo veo más ordenado?
Porque en C y JavaScript lo hago bastante, poner varias instrucciones en una misma línea, sobretodo cuando comparten una estructura común.
A mi en general no me gusta que me lleven con correa como a los perros, me gusta poder decidir cómo hago mis programas.
#36: Lo de los tipos es algo bastante odioso en JavaScript, porque se producen muchas ambigüedades que luego cuesta un montón resolver.
Es mejor tener que poner siempre un "convertir_texto(var)" que andar rebuscando la fuente de un error y que salga de ahí.
En cuanto al indentado de Python no me gusta, porque en general me gusta decidir yo la estructura de mi código, y no que la decida el autor del lenguaje de programación.
Hoy en día existen lenguajes como Rust o Go que pueden sustituir a C en casi cualquier escenario y están mucho mejor preparados para la programación multihilo. Salvo para sistemas legacy donde no quede más remedio que seguir usando C es difícil pensar un escenario donde iniciar un nuevo proyecto con C tenga sentido la verdad.
#16 Yo estoy tentado.
At no point should you be typing the word unsigned into your code. We can now write code without the ugly C convention of multi-word types that impair readability as well as usage. Who wants to type unsigned long long int when you can type uint64_t?
Y luego abajo dice:
Instead of:
long diff = (long)ptrOld - (long)ptrNew;
Use:
ptrdiff_t diff = (uintptr_t)ptrOld - (uintptr_t)ptrNew;
Desde luego dice que ha hecho un borrador, y es que no lo ha revisado.
#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.
#36 Aunque imagino que con lo de "la segunda queja" te refieres a lo que dice #29 sobre Javascript, conste que Python sí es un lenguaje fuertemente tipado, otra cosa es que tenga tipado dinámico y eso pueda gustar más o menos.
Entre otras cosas en Python no puedes concatenar un string y un integer sin realizar una conversión, y otras características de los lenguajes débilmente tipados o no tipados.
#54: Pero el problema está en la falta de libertad.
Si en un programa tengo una estructura con subestructuras y quiero dar valores de inicialización, me gusta agruparlos dentro de una misma línea. También suelo meter en una misma línea los "case - break" de C cuando sólo tienen una instrucción.
#60 Tenia entendido que Python era debilmente tipado. La verdad es que no he trabajado prácticamente nada con el (Alguna tontería jugando con el Euler Project, poco mas). Tienes razón.
Pues yo hasta ahora me he ganado la vida programando en C, C++, Java y C# y si pudiera programaría exclusivamente en C, creo que después de 18 años programando (es decir, sufriendo, programar en España es sufrir) es lo único que me devolvería la ilusión por la profesión.
Me hace gracia que todo el mundo sabe un montón y dicen que C no vale para nada, y resulta que que es el segundo lenguaje más usado del mundo, por detrás de Java.
Que atrevida es la ignorancia.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Pregunta seria de uno que abandonó la programación para escritorio por motivos laborales pero quiere retomar, ¿que lenguaje e IDE se utiliza ahora habitualmente para programar para Windows?
#48 La manía por las llaves se te quita la primera vez que pierdes una mañana porque alguien puso espacios en vez de tabs para indentar.
#55 Porque en C y JavaScript lo hago bastante, poner varias instrucciones en una misma línea, sobretodo cuando comparten una estructura común.
Mereces la muerte a pellizcos, desde el respeto
#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.
#2 Un motivo que veo claro es por la depuración. La gestión manual de punteros y de memoria puede hacer que los programas erroneos no cancelen a veces cuando llegan a una la línea erronea. Un buffer overflow pude hacer que escribas en otra variable a la que accede el programa dentro de media hora. También te puedes cargar el puntero que indica donde esta el area una memória, cuando haces un free de esa area el espacio no se libera y la memoria se va consumiendo. Un día sin más el programa falla y no tienes ni idea que es lo que está pasando. Puedes reducir esto con buenas practicas de programación, pero si programas en equipo nunca vas ha estar completamente seguro de lo que ha echo otra personas. He visto programas que han estado fallando durante meses por que nadie tenia cojones de encontrar el error.
Lenguajes como Java tienen comprobación edinámica de limítes, gestión automática de memoria, etc. Por diseño estos errores son directamente imposibles.
#67: No si lo documentas bien con un comentario.
Cuando hago eso lo que intento es tener un código más compacto al ojo, yo personalmente lo veo mejor así.
#65 Hola, yo diría que Visual Studio para Windows sigue siendo la opción más usada. También Eclipse, Netbeans, etc.
#58 Es que solo la primera recomendación ya es para tirarse de los pelos, lo más ridículo que he leido nunca.
"No usar char, int, short, long..." y sí usar uint8_t, uint32_t .. etc.
La del #pragma once, cuando no es estándar.
La de no utilizar memset, y luego reconocer que su alternativa no sirve debido al padding
La de utilizar arrays dinámicos en lugar de alojar memoria (como si el stack fuese infinito).
La de usar bool en lugar de devolver un valor especial (ptr == NULL), como si fuera una novedad gracias a stdbool
La de no usar malloc...
Pero bueno qué te puedes esperar del idiota que programó redis
El problema del c son los programas de c. Puedes usar el cfree para empezar, pero como quieras usar netbeans o eclipse para c querras morirte. Llevo toda la p mañana intentando meter el mingw. Desde netbeans te mandan a sourceforge, y el exe tiene virus segun virustotal. Sourceforge no es confiable en todo caso. Si lo intentas con eclipse tampoco hay manera. Tener que tocar las paths para que tire es ganas de tocar los huevos. No tengo idea de como hacerlo... ni entiendo para que lo complican todo tanto.
#70 No se me ocurre ninguna situación donde se pueda justificar poner varias instrucciones en una misma linea.
Es mas, el código debería ser autoexplicativo (Salvo en excepciones), si necesitas un comentario es que algo no estás hacienda bien.
#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.
#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.
#12 coño, funcional tener que rematar los strings a mano para que no se vayan de madre...
#73 Uso Eclipse con el plugin de C desde hace más de tres años y estoy contento con él. Me costó un poco al principio, eso sí. Y va muy fluido con disco SSD, antes no.
#61 Sí, te entiendo. Pero lo que te decía es que si te tomas demasiadas "libertades", el programa puede volverse muy difícil de leer. Al final uno con el tiempo termina llegando a al conclusión de que más vale indentar bien y las llaves terminan siendo un estorbo. Ojo, que yo no programo en Python. A pesar de que hace mucho que no lo uso, mi lenguaje preferido es el Pascal y actualmente lo que más uso es PHP, Javascript y a veces C++. Pero reconozco que la sintaxis más estricta de Python es una ventaja.
#19 no entiendo qué le ves de glorioso a un artículo escueto, limitado, y plagado de errores y desinformación. Explícate.
Espero que si programas en C como tu nick indica no hagas las burradas que recomiendan aquí.
#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.
#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á.
#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.
#51 En eso te doy toda la razón. Para programar en C hay que ser muy metódico o tienes leaks por todas partes.
No obstante, yo diría que lo peor de Java es precisamente su ineficiente máquina virtual. La gran mayoría de los programas hechos en Java tienen la estabilidad de un palillo de pie porque los programadores confían pletamente en su JVM.
#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.
#75 El DOOM no era en 3D. Era un modo 7 de toda la vida con sprites 2D. Muy bien logrado, eso si.
#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
#45 Uff, vaya locura. He echado un ojo muy muy por encima, y realmente es el último lenguaje de los que "sé" que elegiría para un proyecto así. Veo que es para la Universidad de Granada.
De lo poco que he podido contrastar fuera del C es el JS, y lo veo a bastante distancia de como yo lo hacía/hago, supongo que porque te has centrado en C. Pero vamos, toda esa gestión de fechas cuando tienes librerías como moment, no le veo mucho sentido (y puedes caparlas todo lo que quieras para que no pesen tanto).
Por cierto, he visto SOAP para ws, ¿pero tienes la parte cliente hecha también en C? En teoría debería estar en el mismo lenguaje para dotarle de ese sentido SOAP (y las estructuras de intercambio XML), ¿no? Y claro, Java Applets, JS,... sí, ¿pero como tiras de C en navegador si no es emscripten?
Lo que más me interesa es saber cual es la razón de diseño por la que decides hacer eso en C, si lo has hecho solo y que cuentes alguna experiencia del proceso.
Un saludo y ánimo.
#63 Pues yo prefiero Rust, pero entiendo que todavia no es la opcion mas evidente por su falta de madurez.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2542865/order/7">#7 c# es c++ para niños
Yo programo en C: y luego guardo el software en cederrones.
Hello world
#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.
Yo soy más de FORTRAN, pero amo al C puro. Siempre seré más de unsigned char que de uint8, y demás enums...
#81 Y no sólo eso. Estan vendiendo teléfonos con procesadores de 8 núcleos de 2Ghz y 3Gb de RAM. Si al menos el kernel y la máquina virtual de Android estuvieran bien optimizados (la optimización es una asignatura pendiente de GCC) o mejor aún escritos en assembler, probablemente nos alcanzaría con un sólo núcleo de por ejemplo 200Mhz, y 128Mb de RAM. La RAM no consume demasiado pero el procesador sí.
Lo que no se podría solucionar es el consumo de la pantalla. Pero recuerda que la mayor parte del tiempo el teléfono está con la pantalla apagada, y en ese estado y con las tremendas baterías que tenemos hoy en día, deberían durar semanas o incluso meses y no es así.
#70 No necesitas hacer cosas raras con las indentaciones. Cada bloque de código es un "nivel más de ejecución".
Ese script de Python lo estoy leyendo perfectamente, sé qué hace y ni sé de qué trata. Anda que no he visto desarrolladores en otros lenguajes liarla parda con las indentaciones.
Si te asusta es porque no sabes programar en Python, igual que a mí a priori me puede asustar Perl o Ruby.
#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.
#66 ESA gente.
Por otro lado debate ya muy antiguo, pero del que siempre defenderé los tabs. Programar con espacios es el mal, pero en Python ya es para mandar a pastar al que lo ha hecho.
#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.
#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.
#86 Claro, era lo que llamaban 2D y medio. O sea escenarios en 3D con sprites en 2D con varias vistas (frente, costado, atrás). Pero el hecho es que lograban mostrar un escenario en 3D sin una placa 3D y con un procesador que con el softare de hoy en día tardaría minutos o hasta horas horas en dibujar lo que hace años hacía en milisegundos.