Te agradecería que si quieres trolear te buscases a otro, hoy ya me has casado bastante.
Y si quieres hacer publicidad de Podemos a pesar de negarlo, búscate una pared y pega propaganda electoral, afíliate, pide tu poltrona en el congreso, o haz lo que tengas que hacer pero no des por culo también en las noticias de tecnología.
Y se usa C porque funciona en cualquier procesador. Por pequeño que sea. Aunque sea un microcontrolador de un robot. Sí, de esos que se les queda bloqueado en Marte por fallos de programación.
Anécdota: De hecho, a raíz de ese robot que se quedó pillado y no había nadie por allí para pulsar [CTRL]+[ALT]+[SUPR] los procesadores tienen un timer que los hace resetear si llega a 0. En el código hay que reiniciar de vez en cuando ese timer. Así, si se mete en un bucle infinito , acabará reiniciandose. Por lo que he visto, otra regla prohibe la recursividad. En la propia regla indica que es por la dificultad de demostrar que no será infinita.
#6:
#4 mira tu propio historial de comentarios y plantéate si es normal comentar única y exclusivamente sobre el mismo tema independientemente de la noticia que se envíe, supongo que entenderás que a muchos nos resulte cansino
#15:
#12 Mi impresión viendo estas reglas es que se pretende garantizar al máximo la estabilidad y seguridad del código, por encima de aprovechar la enorme flexibilidad de C. Por eso se capan muchas posibilidades que harían el código más potente, pero también más susceptible de petar en casos imprevistos. Personalmente, sufriría al programar siguiendo estas normas, pero también dormiría mejor si hubiera personas en el espacio cuyas vidas dependen de alguna manera de mi código.
#18:
#15 Yo tambien lo he revisado, y me parece que la intencion de las normas és permitir que se pueda realizar una validación formal de funcionamiento utilizando algun tipo de herramienta. Por ejemplo la norma 3 impone que todos los bucles deben tener un limite de iteraciones. Con esto garantizas que nunca vas ha quedar en un loop infinito ademas de poder estimar el tiempo máximo que tardara en ejecutarse. Estas restricciones són tipicas para sistemas en tiempo real.
Respecto a no utilizar un lenguage mas moderno, lo mismo. El compilador tambien genera su parte de problemas y el lenguage su parte de incertidumbre. Todos los lenguages con garbage collection quedan descartados por no poder predecir cuanto tiempo se va a perder gestionando la memoria ni cuanto espacio va a consumir.
#35:
#32 eso fue el Ariane 5 no el Challenger. Y no fue un errro de programación como tal, si no un error basado en este tipo de protocolos y autolimitaciones: no activar gestor de excepciones para mantener el uso CPU por debajo de 80%.
#26:
Lo raro es que existiendo cosas como Ada, desarrollado con la fiabilidad, seguridad y predicibilidad en mente específicamente para sistemas críticos y en tiempo real (ejército, aviones, etc.), usasen C con corsés normativos, que es algo que te puede traicionar en cualquier momento como de hecho alguna vez ocurrió.
#17:
Lo de usar el flag de pedantic es para masoquistas, porque dependiendo del compilador te soltará unos warnings u otros, ya que ningun compilador sigue 100% el standard. Tambien me sorprende que no incluyan algo tan básico como inicializar todas las variables.
#32:
#31 y #26: Ada tampoco es infalible, el accidente del Challenger se produjo por culpa de una excepción no controlada en un programa escrito en Ada. Sea cual sea el lenguaje, siempre es buena idea poner unos límites cuando se trata de sistemas críticos.
#19:
#15 Son reglas para sistemas críticos, lo dice el propio informe. Códigos cortos donde lo crítico es la fiabilidad. Buena suerte si pretendes programar una red neuronal o un sistema de reconocimiento de imágenes.
#23:
#22 Evidentemente utilizan GCC. Aunque no está en el standard, GCC inicializa todas las variables a zero cuando se declaran; otros compilaodores no, porque no es parte del standard.
Yo ya me he encontrado un código que saltaban errores de ejecución cuando lo compilabas con el Visual Studio y decian que era problema del compilador. Luego miras el código y te das cuenta que el tio no inicializaba las variables, a parte de ser una chapuza de código escrita con el vim.
#4 mira tu propio historial de comentarios y plantéate si es normal comentar única y exclusivamente sobre el mismo tema independientemente de la noticia que se envíe, supongo que entenderás que a muchos nos resulte cansino
#32 eso fue el Ariane 5 no el Challenger. Y no fue un errro de programación como tal, si no un error basado en este tipo de protocolos y autolimitaciones: no activar gestor de excepciones para mantener el uso CPU por debajo de 80%.
Lo raro es que existiendo cosas como Ada, desarrollado con la fiabilidad, seguridad y predicibilidad en mente específicamente para sistemas críticos y en tiempo real (ejército, aviones, etc.), usasen C con corsés normativos, que es algo que te puede traicionar en cualquier momento como de hecho alguna vez ocurrió.
#31 y #26: Ada tampoco es infalible, el accidente del Challenger se produjo por culpa de una excepción no controlada en un programa escrito en Ada. Sea cual sea el lenguaje, siempre es buena idea poner unos límites cuando se trata de sistemas críticos.
#32 Que yo sepa fue por una junta que no soporto las bajas temperaturas de un deposito y como que una fuga de hidrógeno teniendo un mechero gigante cerca no es buena idea.
#16#26 Nadie ha dicho que solamente programen en C. Cualquier proyecto mas o menos grande acaba teniendo código en diferentes lenguajes. Ni hablemos cuando se trata de cientos de proyectos.
Creo que este documento debe abordarse más con el objetivo de hacer que el código no falle, que debatir cual es el mejor lenguaje.
#49 definir una función es lo mismo que definir un puntero constante a ella. Claro que tiene sentido la restricción, de hecho existen otros lenguajes que tienen esa restricción implícita. La cuestión es por qué no usan esos directamente, que es en lo que estamos y que ya hay bastante comentado. #27
Hasta ahí llegamos. En C se puede hacer de todo, para lo bueno y para lo malo.
No deben tener sencillo traducir desde otros lenguajes de tipado más robusto a C. #21 sip, tiene sentido, yo me apunto a esa tesis. Ahora solo falta que alguien que trabaje en la nasa nos lo confirme #57 sin acritud: tu compara tu aporte al debate con los del resto. #52 cientos de proyectos y decenas de lenguajes los tiene una empresa grande sin necesidad de tener perfil tecnológico. En la nasa deben moverse en un orden de magnitud de miles o cientos de miles. Sería interesante ver el ciclo completo de SQA; las reglas de codificación son solo una pequeña parte y supongo no la más importante.
#71 Sin acritud, si no entendiste el mensaje detrás del sarcasmo es tu problema.
Por si no lo pillas, estoy seguro que esa gente tiene una razón perfectamente lógica para cada punto de ese estándar, y he usado el sarcasmo para mostrar la gracia que me ha hecho tu amago de duda al respecto.
PD. Por cierto, muy bonito lo de editar el mensaje.
#72 lo pillo perfectamente. Como en la nasa no son tontos, el tonto soy yo por cuestionar.
Que soy tonto lo tengo asumido desde que suspendí el primer examen y corté con la primera novia. Pero no suelo entrar a discutir esas cosas, como comprenderás. Ni lo de editar.
MNM es libre, cada uno se mueve aquí como quiere. Lo de sin acritud era sincero.
#76 Si estas dando a entender que te he llamado tonto a ti estas suspendido en lógica, decir que la NASA no es tonta no implica que lo seas tu, así que no vengas con falsos victimismos.
He dicho que me hace gracia que lo cuestiones, nada mas, pero como has editado tu comentario, las respuestas dejan de tener sentido.
Un saludo.
#44 el goto se debe usar siempre que sea necesario. Es decir: nunca. #22 está por ver todavía el primer centro de desarrollo donde tengan recursos para hacer todo lo que quieran y más. #71 lo pillo perfectamente. Como en la nasa no son tontos, el tonto soy yo por cuestionar.
Que soy tonto lo tengo asumido desde que suspendí el primer examen y corté con la primera novia. Pero no suelo entrar a discutir esas cosas, como comprenderás. Ni lo de editar.
MNM es libre, cada uno se mueve aquí como quiere. Lo de sin acritud era sincero.
#71 por la inmensa cantidad de herramientas que existen para c y para ningun otro lenguaje. Si consideras c como una especie de ensamblador todo cobra sentido. Muchos de los que trabajamos en sistemas empotrados usamos c pensando en el codigo que genera en lugar de la filosofia del lenguaje, que es lo que tocaria realmente.
#26 Dicen que uno de los grandes retrasos y sobrecostes del programa J35 es por el Ada. El leguaje estará todo lo bien que quieran, pero no tiene el soporte de un buen IDE, entornos de desarrollo y depuradores que tiene el C.
#26 siempre me ha llamado la atención el poco exito que tuvo ada, incluso en los sectores hacia donde estaba dirigido, todavia veo gente que programa en pl/1 pero de ada nunca mas se supo.
Lo de usar el flag de pedantic es para masoquistas, porque dependiendo del compilador te soltará unos warnings u otros, ya que ningun compilador sigue 100% el standard. Tambien me sorprende que no incluyan algo tan básico como inicializar todas las variables.
#22 Evidentemente utilizan GCC. Aunque no está en el standard, GCC inicializa todas las variables a zero cuando se declaran; otros compilaodores no, porque no es parte del standard.
Yo ya me he encontrado un código que saltaban errores de ejecución cuando lo compilabas con el Visual Studio y decian que era problema del compilador. Luego miras el código y te das cuenta que el tio no inicializaba las variables, a parte de ser una chapuza de código escrita con el vim.
#23 Esta es una de las muchas cosas que fastidian de C y C++: Undefined Behaviour. Por eso me gusta Rust, pero le queda un larguísimo camino todavía...
#22 En absoluto. El presupuesto de la NASA va ajustadísimo, y crear (y mantener) un compilador consistente que genere código decente no es moco de pavo, y menos cuando hablamos de un animal tan difícil de domar como C.
#16 Pues porque C está probado, porque el hardware que tienen soporta C y lo mismo no soporta Rust, y porque hay programas que analizan el código de C y comprueban que no tiene multitud de tipos de errores (validación formal), cosa que con otros lenguajes no ocurre.
#54 Supongo que te refieres a la diferencia entre lenguajes como C/C++ donde se realiza una gestión manual de la memoria y lenguajes como Java o Javascript que hacen uso de recolectores de basura. Rust es como C/C++ en ese aspecto, y en principio tienes que hacer tú mismo el trabajo sucio. Eso me gusta. Por supuesto, si quieres hacer uso de un recolector de basura, también puedes, no tienes más que usar alguna librería para ello (igual que en C++).
#40 No he especificado de qué otros lenguajes hablo, ni a qué dispositivos/hardware me refiero, así que tú digas que no es cierto me parece sorprendente.
#61 Es difícil generalizar especificando . La cosa es que Para muchos dispositivos hardware, el número de herramientas, compiladores etc es bastante limitado. Por su uso pervasivo, su historia, y por la facilidad de implementar un compilador de C (ya que es un lenguaje relativamente pequeño, que no sencillo, y relativamente cercano al ensamblador/metal), normalmente siempre puedes contar con un compilador de C.
#40 Error de lógica formal. "muchos lenguajes lo tienen" no invalida "que con otros lenguajes no ocurre." Lo único que invalidaría "que con otros lenguajes no ocurre" sería que ocurriera en todos. Como, de hecho, no es así, la frase de #21 es cierta.
#16#21 Los dos motivos que más se dan para promover el uso de C/C++ en sistemas embebidos real-time o safety-critical son:
1. Que C/C++ son lenguajes muy conocidos y, por tanto, hay muchos programadores que saben programas en esos lenguajes, mientras que hay muchos menos programadores que sepan otros lenguajes más idóneos, como Ada.
2. Que la mayor parte de los vendors de microcontroladores proporcionan compiladores para C/C++, pero no para otros lenguajes más exóticos, como podría ser Ada.
Dicho esto, me sigue pareciendo una locura usar C/C++ por la gran cantidad de errores que se pueden cometer, incluso un programador experimentados y versado en las intricacies de C/C++.
#12 Para paliar los peligros de C/C++ es por lo que surgen estándares de codificación como MISRA y estos estándares de la NASA/JPL. Si estos estándares prohiben usar features de C/C++, es porque esas features son PELIGROSAS (con todas las letras y en mayúsculas).
#25 técnicamente es dirigida por la NASA pero la organización padre es Calltech.
Del propio documento: Acknowledgement
The research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.
#13 decides no usar algo que es potente y que lo diferencia de otros muchos lenguajes. Por poner un caso, te complica el código de una simple calculadora. #15 sip. Y la pregunta siguiente es por qué no pasan de C y usan alguno de los lenguajes que tienen capadas esas posibilidades de serie. Puede haber decenas de respuestas.
Y se usa C porque funciona en cualquier procesador. Por pequeño que sea. Aunque sea un microcontrolador de un robot. Sí, de esos que se les queda bloqueado en Marte por fallos de programación.
Anécdota: De hecho, a raíz de ese robot que se quedó pillado y no había nadie por allí para pulsar [CTRL]+[ALT]+[SUPR] los procesadores tienen un timer que los hace resetear si llega a 0. En el código hay que reiniciar de vez en cuando ese timer. Así, si se mete en un bucle infinito , acabará reiniciandose. Por lo que he visto, otra regla prohibe la recursividad. En la propia regla indica que es por la dificultad de demostrar que no será infinita.
#27#15 Solo añadir que si algo hay depurado, es el compilador gcc, es a prueba de bombas, y quizá sea el compilador soportado por más tipos de arquitecturas, sean del año que sean.
Reconozco que odio C, y con estas limitaciones, lo odiaría mucho más, pero hay que reconocer que si uno necesita un binario fiable y predecible, ha de usar C y gcc por fuerza mayor.
#12 Mi impresión viendo estas reglas es que se pretende garantizar al máximo la estabilidad y seguridad del código, por encima de aprovechar la enorme flexibilidad de C. Por eso se capan muchas posibilidades que harían el código más potente, pero también más susceptible de petar en casos imprevistos. Personalmente, sufriría al programar siguiendo estas normas, pero también dormiría mejor si hubiera personas en el espacio cuyas vidas dependen de alguna manera de mi código.
#15 Yo tambien lo he revisado, y me parece que la intencion de las normas és permitir que se pueda realizar una validación formal de funcionamiento utilizando algun tipo de herramienta. Por ejemplo la norma 3 impone que todos los bucles deben tener un limite de iteraciones. Con esto garantizas que nunca vas ha quedar en un loop infinito ademas de poder estimar el tiempo máximo que tardara en ejecutarse. Estas restricciones són tipicas para sistemas en tiempo real.
Respecto a no utilizar un lenguage mas moderno, lo mismo. El compilador tambien genera su parte de problemas y el lenguage su parte de incertidumbre. Todos los lenguages con garbage collection quedan descartados por no poder predecir cuanto tiempo se va a perder gestionando la memoria ni cuanto espacio va a consumir.
#15 Son reglas para sistemas críticos, lo dice el propio informe. Códigos cortos donde lo crítico es la fiabilidad. Buena suerte si pretendes programar una red neuronal o un sistema de reconocimiento de imágenes.
#15 La gran potencia y flexibilidad del C podría calificarse de diabólica por el precio de inseguridad que puede tener a la mínima torpeza. Los tipos de warnings que pueden generar algunos compiladores actuales son muy amplios. Cada uno de ellos se refiere a la inseguridad potencial de alguna práctica.
Por ello, creo que los compiladores no solo deberían ser capaces de ofrecer un modo amplio de avisos (warnings) sino que para cada tipo de ellos, el propio compilador debería ofrecer un enlace web con información adicional, porque no todos los warnings resultan triviales y obvios.
En otras palabras, los compiladores de C en particular podrían ir acompañados de funcionalidad didáctica, porque no hay nada más educactivo que aprender de los errores propios.
#12 pero punteros const a funciones si que se puede, esta restriccion tiene todo el sentido del mundo. Te impide ejecutar una direccion de memoria. fnptr=0x1234; fnptr(); por ejemplo. Hacer esto puede ser necesario si programas contra contra hardware puro y duro, pero es muy peligroso si estas bajo un sistema operativo.
#12 el razonamiento viene de una de las reglas MISRA que no aparecen por ser propietarias.
Se quiere evitar ejecutar una direction de memoria que se desconozca a priori o, en el peor de los casos, memoria corrupta. En un sistema embebido los punteros constantes se almacenan en ROM lo que garantiza que no se corrompa, por eso se permiten.
#105 PS #12 No conozco muchas situaciones en las que necesites un puntero no constante a función. La regla 29 no prohibe pasar punteros no constantes como argumentos de función, sino usar punteros no constantes que apunten a una función.
#11 no, jpl, a pesar de su nombre en la actualidad no tiene nada que ver con cohetes, es el lavoratorio de la nasa principalmemte encargado de las sondas y robots interplanetarios. Su nombre viene de que en sus inicios fueron sobretodo a la creación de motores y cohetes, pero eso ya no tiene nada que ver con el jpl actual
#14 El JPL sigue haciendo cosas relacionadas con cohetes pero, en cualquier caso, sigue siendo parte de la NASA. Que hagan cohetes o no no tiene nada que ver con la noticia: es correcto decir que son la NASA.
#20 y #25 pues leeme tú tmb, yo también he dicho que es de la nasa . Mi 'no' era a que no es de cohetes desde hace muchísimos años, ahora es la parte de la nasa q se dedica a la exploración interplanetaria. Ups, exactamente lo que dije en el otro comentario ;).
#34 Creo que el problema es que no has visto que un usuario es al que le has dicho que sí son de la NASA, y otro usuario es el que te ha dicho que ya no son el laboratorio de cohetes.
#93 Ya lo hago. Lo ejecuto paso a paso. Puede que se trate de una librería de terceros (ComponentAce) la que esté generando el problema. Aunque tengo el código fuente, no voy a meterme ahí ni loco, prefiero eliminar las referencias a la librería. Ya veré como me las arreglo.
#78 No, esta vez me he topado con tu comentario por casualidad. Normalmente me invocas para insultarme personalmente, pero veo que también recurres a la más cobarde difamación.
Lo dicho, mi niño acosador, no te obsesiones. Vivirás mejor.
Y no te equivoques, chiquitín, que tú le dés tantísima importancia a Menéame no significa que los demás también lo hagamos.
Sólo te recuerdo de verte aparecer en mis conversaciones para insultarme, no esperes que haga como tú y me grabe en la memoria dónde y por qué.
También me acuerdo de haberme tirado un cuesco esta mañana, y para que te hagas una idea el cuesco me importa más que tú.
A los trolls seguidistas como tú os llamo ”acólitos”, y me parto risa sólo de pensar que dedicáis tiempo a bucear en Menéame buscándome para nada. Qué vida más triste la vuestra.
Te agradecería que si quieres trolear te buscases a otro, hoy ya me has casado bastante.
Y si quieres hacer publicidad de Podemos a pesar de negarlo, búscate una pared y pega propaganda electoral, afíliate, pide tu poltrona en el congreso, o haz lo que tengas que hacer pero no des por culo también en las noticias de tecnología.
#3 Por no hacer caso de un warning, dado que compila y se ejecuta perfectamente, llevo un año con una "memory leak" que me genera errores muy de tiempo en tiempo. El código parece perfecto, sigo las sugerencias del compilador. Al final, va a tener razón el autor: Reescribe el código. Lo malo es que es una jodida clase con muchas propiedades y eventos y me da pereza reescribirla.
#2 En todo caso está generando animadversión hacia Podemos, sicología inversa... y gracias a que le das de comer pues ya tienes tu karma respectivo, como la DEA con el narcotráfico.
Comentarios
#4 mira tu propio historial de comentarios y plantéate si es normal comentar única y exclusivamente sobre el mismo tema independientemente de la noticia que se envíe, supongo que entenderás que a muchos nos resulte cansino
#32 eso fue el Ariane 5 no el Challenger. Y no fue un errro de programación como tal, si no un error basado en este tipo de protocolos y autolimitaciones: no activar gestor de excepciones para mantener el uso CPU por debajo de 80%.
#35 Por no hablar de la decisión política (o de "gestión") de reutilizar el software del Ariane-4 tal cual...
#4 Deja de hacer el ridículo.
Lo raro es que existiendo cosas como Ada, desarrollado con la fiabilidad, seguridad y predicibilidad en mente específicamente para sistemas críticos y en tiempo real (ejército, aviones, etc.), usasen C con corsés normativos, que es algo que te puede traicionar en cualquier momento como de hecho alguna vez ocurrió.
#26 Eso iba a poner, que programen en Ada.
#31 y #26: Ada tampoco es infalible, el accidente del Challenger se produjo por culpa de una excepción no controlada en un programa escrito en Ada. Sea cual sea el lenguaje, siempre es buena idea poner unos límites cuando se trata de sistemas críticos.
#32 Que yo sepa fue por una junta que no soporto las bajas temperaturas de un deposito y como que una fuga de hidrógeno teniendo un mechero gigante cerca no es buena idea.
#31 Si, yo también pensé en ADA, pero luego dije: Vaya, quizás no es soportado en los micros que utilizan.
#26
No hay nada como el Ook!.
#33 Aquí en MNM se es más del Hodor... http://www.hodor-lang.org/
#16 #26 Nadie ha dicho que solamente programen en C. Cualquier proyecto mas o menos grande acaba teniendo código en diferentes lenguajes. Ni hablemos cuando se trata de cientos de proyectos.
Creo que este documento debe abordarse más con el objetivo de hacer que el código no falle, que debatir cual es el mejor lenguaje.
#49 definir una función es lo mismo que definir un puntero constante a ella. Claro que tiene sentido la restricción, de hecho existen otros lenguajes que tienen esa restricción implícita. La cuestión es por qué no usan esos directamente, que es en lo que estamos y que ya hay bastante comentado.
#27
Hasta ahí llegamos. En C se puede hacer de todo, para lo bueno y para lo malo.
No deben tener sencillo traducir desde otros lenguajes de tipado más robusto a C.
#21 sip, tiene sentido, yo me apunto a esa tesis. Ahora solo falta que alguien que trabaje en la nasa nos lo confirme
#57 sin acritud: tu compara tu aporte al debate con los del resto.
#52 cientos de proyectos y decenas de lenguajes los tiene una empresa grande sin necesidad de tener perfil tecnológico. En la nasa deben moverse en un orden de magnitud de miles o cientos de miles. Sería interesante ver el ciclo completo de SQA; las reglas de codificación son solo una pequeña parte y supongo no la más importante.
#71 Sin acritud, si no entendiste el mensaje detrás del sarcasmo es tu problema.
Por si no lo pillas, estoy seguro que esa gente tiene una razón perfectamente lógica para cada punto de ese estándar, y he usado el sarcasmo para mostrar la gracia que me ha hecho tu amago de duda al respecto.
PD. Por cierto, muy bonito lo de editar el mensaje.
#72 lo pillo perfectamente. Como en la nasa no son tontos, el tonto soy yo por cuestionar.
Que soy tonto lo tengo asumido desde que suspendí el primer examen y corté con la primera novia. Pero no suelo entrar a discutir esas cosas, como comprenderás. Ni lo de editar.
MNM es libre, cada uno se mueve aquí como quiere. Lo de sin acritud era sincero.
#76 Si estas dando a entender que te he llamado tonto a ti estas suspendido en lógica, decir que la NASA no es tonta no implica que lo seas tu, así que no vengas con falsos victimismos.
He dicho que me hace gracia que lo cuestiones, nada mas, pero como has editado tu comentario, las respuestas dejan de tener sentido.
Un saludo.
#87 no te preocupes, no me he ofendido. No tiene importancia.
No he editado, pero eso tampoco la tiene.
#96 Entonces me habré confundido, te pido disculpas.
#44 el goto se debe usar siempre que sea necesario. Es decir: nunca.
#22 está por ver todavía el primer centro de desarrollo donde tengan recursos para hacer todo lo que quieran y más.
#71 lo pillo perfectamente. Como en la nasa no son tontos, el tonto soy yo por cuestionar.
Que soy tonto lo tengo asumido desde que suspendí el primer examen y corté con la primera novia. Pero no suelo entrar a discutir esas cosas, como comprenderás. Ni lo de editar.
MNM es libre, cada uno se mueve aquí como quiere. Lo de sin acritud era sincero.
#71 por la inmensa cantidad de herramientas que existen para c y para ningun otro lenguaje. Si consideras c como una especie de ensamblador todo cobra sentido. Muchos de los que trabajamos en sistemas empotrados usamos c pensando en el codigo que genera en lugar de la filosofia del lenguaje, que es lo que tocaria realmente.
#26 Dicen que uno de los grandes retrasos y sobrecostes del programa J35 es por el Ada. El leguaje estará todo lo bien que quieran, pero no tiene el soporte de un buen IDE, entornos de desarrollo y depuradores que tiene el C.
#26 siempre me ha llamado la atención el poco exito que tuvo ada, incluso en los sectores hacia donde estaba dirigido, todavia veo gente que programa en pl/1 pero de ada nunca mas se supo.
Lo de usar el flag de pedantic es para masoquistas, porque dependiendo del compilador te soltará unos warnings u otros, ya que ningun compilador sigue 100% el standard. Tambien me sorprende que no incluyan algo tan básico como inicializar todas las variables.
#17 Esta gente tiene suficientes recursos como para mantener su propio compilador, diría yo.
#22 Evidentemente utilizan GCC. Aunque no está en el standard, GCC inicializa todas las variables a zero cuando se declaran; otros compilaodores no, porque no es parte del standard.
Yo ya me he encontrado un código que saltaban errores de ejecución cuando lo compilabas con el Visual Studio y decian que era problema del compilador. Luego miras el código y te das cuenta que el tio no inicializaba las variables, a parte de ser una chapuza de código escrita con el vim.
#23 Esta es una de las muchas cosas que fastidian de C y C++: Undefined Behaviour. Por eso me gusta Rust, pero le queda un larguísimo camino todavía...
#23 ¿Qué tiene vim que ver con la chapuza?
#58 Una regla que se erifica casi al 100% es que si tu editor o tu IDE es una mierda, tu código será una mierda. Da igual lo bueno que te creas.
#89 Te queda mucho por aprender, pequeño Padawan.
#23 ¿Y qué tiene el editor que ver con que el resultado sea una chapuza?
#23 Alguna referencia sobre la initialización a cero de gcc?
#81 eso no tiene nada que ver con gcc, la especificacion es clara.
#22 En absoluto. El presupuesto de la NASA va ajustadísimo, y crear (y mantener) un compilador consistente que genere código decente no es moco de pavo, y menos cuando hablamos de un animal tan difícil de domar como C.
#16 Pues porque C está probado, porque el hardware que tienen soporta C y lo mismo no soporta Rust, y porque hay programas que analizan el código de C y comprueban que no tiene multitud de tipos de errores (validación formal), cosa que con otros lenguajes no ocurre.
#21 el hardware no soporta C, solo soporta binario.
#28 Correcto, me refería a que a menudo no hay soporte/compiladores para otros lenguajes más extraños o novedosos, como Rust.
#30 Una pregunta (parece que usted controla): ¿soporta rush recolección de memoria?
#54 Supongo que te refieres a la diferencia entre lenguajes como C/C++ donde se realiza una gestión manual de la memoria y lenguajes como Java o Javascript que hacen uso de recolectores de basura. Rust es como C/C++ en ese aspecto, y en principio tienes que hacer tú mismo el trabajo sucio. Eso me gusta. Por supuesto, si quieres hacer uso de un recolector de basura, también puedes, no tienes más que usar alguna librería para ello (igual que en C++).
#64 Si, exacto
#21 "cosa que con otros lenguajes no ocurre"
No es cierto. Muchos lenguajes lo tienen, además de suites de test variadas.
#40 No he especificado de qué otros lenguajes hablo, ni a qué dispositivos/hardware me refiero, así que tú digas que no es cierto me parece sorprendente.
#60 Has generalizado sin especificar, por lo que yo he respondido generalizando.
#61 Es difícil generalizar especificando . La cosa es que Para muchos dispositivos hardware, el número de herramientas, compiladores etc es bastante limitado. Por su uso pervasivo, su historia, y por la facilidad de implementar un compilador de C (ya que es un lenguaje relativamente pequeño, que no sencillo, y relativamente cercano al ensamblador/metal), normalmente siempre puedes contar con un compilador de C.
#40 Error de lógica formal. "muchos lenguajes lo tienen" no invalida "que con otros lenguajes no ocurre." Lo único que invalidaría "que con otros lenguajes no ocurre" sería que ocurriera en todos. Como, de hecho, no es así, la frase de #21 es cierta.
#65 No, porque he dicho que con otros lenguajes no ocurre. No he dicho que con todos los demás no ocurra.
#66 Y por eso he dicho que tu frase de #21 es cierta...
#16 #21 Los dos motivos que más se dan para promover el uso de C/C++ en sistemas embebidos real-time o safety-critical son:
1. Que C/C++ son lenguajes muy conocidos y, por tanto, hay muchos programadores que saben programas en esos lenguajes, mientras que hay muchos menos programadores que sepan otros lenguajes más idóneos, como Ada.
2. Que la mayor parte de los vendors de microcontroladores proporcionan compiladores para C/C++, pero no para otros lenguajes más exóticos, como podría ser Ada.
Dicho esto, me sigue pareciendo una locura usar C/C++ por la gran cantidad de errores que se pueden cometer, incluso un programador experimentados y versado en las intricacies de C/C++.
#12 Para paliar los peligros de C/C++ es por lo que surgen estándares de codificación como MISRA y estos estándares de la NASA/JPL. Si estos estándares prohiben usar features de C/C++, es porque esas features son PELIGROSAS (con todas las letras y en mayúsculas).
Rule 11 (simple control flow)
The goto statement shall not be used.
#39 Cocopino al menos era majete. Este es como mucho ese otro que has dicho.
#25 técnicamente es dirigida por la NASA pero la organización padre es Calltech.
Del propio documento: Acknowledgement
The research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.
© 2009 California Institute of Technology. Government sponsorship is acknowledged.
Así que me da que es solo el estándar del JPL, no de toda la NASA aunque supongo que serán muy parecidos.
#45 Lo dice la entradilla.
#48 respondí al comentario, no a la noticia.
#45 Y es para quien trabaja Wolowitz
http://bigbangtheory.wikia.com/wiki/Jet_Propulsion_Laboratory
Rule 29
Non-constant pointers to functions should not be used.
Vaya C de chichinabo entonces.
#12 ¿Por?
#13 decides no usar algo que es potente y que lo diferencia de otros muchos lenguajes. Por poner un caso, te complica el código de una simple calculadora.
#15 sip. Y la pregunta siguiente es por qué no pasan de C y usan alguno de los lenguajes que tienen capadas esas posibilidades de serie. Puede haber decenas de respuestas.
#16 Se hace por evitar bugs, como indica #15.
http://stackoverflow.com/a/10145901
Y se usa C porque funciona en cualquier procesador. Por pequeño que sea. Aunque sea un microcontrolador de un robot. Sí, de esos que se les queda bloqueado en Marte por fallos de programación.
Anécdota: De hecho, a raíz de ese robot que se quedó pillado y no había nadie por allí para pulsar [CTRL]+[ALT]+[SUPR] los procesadores tienen un timer que los hace resetear si llega a 0. En el código hay que reiniciar de vez en cuando ese timer. Así, si se mete en un bucle infinito , acabará reiniciandose. Por lo que he visto, otra regla prohibe la recursividad. En la propia regla indica que es por la dificultad de demostrar que no será infinita.
#27 sobre el timer que hablas... https://en.m.wikipedia.org/wiki/Watchdog_timer
#43 #27 lo que provoco ese fallo tambien es curioso de saber https://es.wikipedia.org/wiki/Inversi%C3%B3n_de_prioridades?wprov=sfla1
#27 #15 Solo añadir que si algo hay depurado, es el compilador gcc, es a prueba de bombas, y quizá sea el compilador soportado por más tipos de arquitecturas, sean del año que sean.
Reconozco que odio C, y con estas limitaciones, lo odiaría mucho más, pero hay que reconocer que si uno necesita un binario fiable y predecible, ha de usar C y gcc por fuerza mayor.
#16 Es que los de la NASA son tontos
#12 Mi impresión viendo estas reglas es que se pretende garantizar al máximo la estabilidad y seguridad del código, por encima de aprovechar la enorme flexibilidad de C. Por eso se capan muchas posibilidades que harían el código más potente, pero también más susceptible de petar en casos imprevistos. Personalmente, sufriría al programar siguiendo estas normas, pero también dormiría mejor si hubiera personas en el espacio cuyas vidas dependen de alguna manera de mi código.
#15 Yo tambien lo he revisado, y me parece que la intencion de las normas és permitir que se pueda realizar una validación formal de funcionamiento utilizando algun tipo de herramienta. Por ejemplo la norma 3 impone que todos los bucles deben tener un limite de iteraciones. Con esto garantizas que nunca vas ha quedar en un loop infinito ademas de poder estimar el tiempo máximo que tardara en ejecutarse. Estas restricciones són tipicas para sistemas en tiempo real.
Respecto a no utilizar un lenguage mas moderno, lo mismo. El compilador tambien genera su parte de problemas y el lenguage su parte de incertidumbre. Todos los lenguages con garbage collection quedan descartados por no poder predecir cuanto tiempo se va a perder gestionando la memoria ni cuanto espacio va a consumir.
#18 Vas a quedar no "vas ha quedar".
#15 Son reglas para sistemas críticos, lo dice el propio informe. Códigos cortos donde lo crítico es la fiabilidad. Buena suerte si pretendes programar una red neuronal o un sistema de reconocimiento de imágenes.
#15 La gran potencia y flexibilidad del C podría calificarse de diabólica por el precio de inseguridad que puede tener a la mínima torpeza. Los tipos de warnings que pueden generar algunos compiladores actuales son muy amplios. Cada uno de ellos se refiere a la inseguridad potencial de alguna práctica.
Por ello, creo que los compiladores no solo deberían ser capaces de ofrecer un modo amplio de avisos (warnings) sino que para cada tipo de ellos, el propio compilador debería ofrecer un enlace web con información adicional, porque no todos los warnings resultan triviales y obvios.
En otras palabras, los compiladores de C en particular podrían ir acompañados de funcionalidad didáctica, porque no hay nada más educactivo que aprender de los errores propios.
#12 pero punteros const a funciones si que se puede, esta restriccion tiene todo el sentido del mundo. Te impide ejecutar una direccion de memoria. fnptr=0x1234; fnptr(); por ejemplo. Hacer esto puede ser necesario si programas contra contra hardware puro y duro, pero es muy peligroso si estas bajo un sistema operativo.
#12 el razonamiento viene de una de las reglas MISRA que no aparecen por ser propietarias.
Se quiere evitar ejecutar una direction de memoria que se desconozca a priori o, en el peor de los casos, memoria corrupta. En un sistema embebido los punteros constantes se almacenan en ROM lo que garantiza que no se corrompa, por eso se permiten.
#105 PS #12 No conozco muchas situaciones en las que necesites un puntero no constante a función. La regla 29 no prohibe pasar punteros no constantes como argumentos de función, sino usar punteros no constantes que apunten a una función.
JPL != NASA
#10 JPL es el laboratorio de propulsión de cohetes de la NASA: http://jpl.nasa.gov
#11 no, jpl, a pesar de su nombre en la actualidad no tiene nada que ver con cohetes, es el lavoratorio de la nasa principalmemte encargado de las sondas y robots interplanetarios. Su nombre viene de que en sus inicios fueron sobretodo a la creación de motores y cohetes, pero eso ya no tiene nada que ver con el jpl actual
#14 El JPL sigue haciendo cosas relacionadas con cohetes pero, en cualquier caso, sigue siendo parte de la NASA. Que hagan cohetes o no no tiene nada que ver con la noticia: es correcto decir que son la NASA.
#20 y #25 pues leeme tú tmb, yo también he dicho que es de la nasa . Mi 'no' era a que no es de cohetes desde hace muchísimos años, ahora es la parte de la nasa q se dedica a la exploración interplanetaria. Ups, exactamente lo que dije en el otro comentario ;).
Sorry por la v
#29 Entonces no consigo entender dónde ves el problema.
#34 Creo que el problema es que no has visto que un usuario es al que le has dicho que sí son de la NASA, y otro usuario es el que te ha dicho que ya no son el laboratorio de cohetes.
Aclaro que yo son un tercer usuario.
#83 Hola, soy todos los usuarios anteriores fusionados en un cuarto usuario.
#14 Laboratorio es con B.
y el JPL forma parte de la NASA vuelve a leer #11.
#14 Escrito con móvil? Lavoratorio? Hacen lavativas?
#70: Puedes... no sé, depurar el código.
#93 Ya lo hago. Lo ejecuto paso a paso. Puede que se trate de una librería de terceros (ComponentAce) la que esté generando el problema. Aunque tengo el código fuente, no voy a meterme ahí ni loco, prefiero eliminar las referencias a la librería. Ya veré como me las arreglo.
Como firme defensor de la programación defensiva, leo con interés. De hecho lo voy a guardar y todo.
#39 Estás obsesionado conmigo, chatín. Se te nota el escozor.
Y yo ni recuerdo dónde te he visto.
#75 en meneame,donde esta tu vida...no he puesto ni el @ para invocarte...
#78 No, esta vez me he topado con tu comentario por casualidad. Normalmente me invocas para insultarme personalmente, pero veo que también recurres a la más cobarde difamación.
Lo dicho, mi niño acosador, no te obsesiones. Vivirás mejor.
Y no te equivoques, chiquitín, que tú le dés tantísima importancia a Menéame no significa que los demás también lo hagamos.
#79 no decias que no te acordabas de mi? Pues eso....
#99 Lee otra vez, payasete, que ni eso sabes.
Sólo te recuerdo de verte aparecer en mis conversaciones para insultarme, no esperes que haga como tú y me grabe en la memoria dónde y por qué.
También me acuerdo de haberme tirado un cuesco esta mañana, y para que te hagas una idea el cuesco me importa más que tú.
A los trolls seguidistas como tú os llamo ”acólitos”, y me parto risa sólo de pensar que dedicáis tiempo a bucear en Menéame buscándome para nada. Qué vida más triste la vuestra.
Cosa que no interesa a nadie pero meneamos para hacernos los interesantes.
#92 hasta que alguien lo lee, y como buen cuñado, corrige y perfecciona para mejorar la seguridad y eficiencia de la NASA
#4 Podías irte tomar por el culo sin acritud.
#4 Piérdete, imbécil.
#4 A mí me ha hecho gracia. Lo que no te voto positivo por el karma y eso.
Un día de estos voy a subir el Neufert a ver si hago portada.
#quierocreer
#4 En Canarias usamos una expresión divertida para este tipo de situaciones: "Tírate al suelo y di que te dió un dolor".
#85 Sí.
Con el dinero que nos roban, estoy convencido de que Podemos podría crear una NASA española.
#1 Aquí tienes tu premio:
Te agradecería que si quieres trolear te buscases a otro, hoy ya me has casado bastante.
Y si quieres hacer publicidad de Podemos a pesar de negarlo, búscate una pared y pega propaganda electoral, afíliate, pide tu poltrona en el congreso, o haz lo que tengas que hacer pero no des por culo también en las noticias de tecnología.
#2 Es repugnante el spam de este tío
@pacofrancogoilgolzarri
Y te lo dice un votante de Podemos
Algún@admin debería mirarlo.
#3 Gracias@Lobazo.
#5 se cree el nuevo
#9 ese tenia gracia...este es un cocopino o malversan como mucho...
#3 Por no hacer caso de un warning, dado que compila y se ejecuta perfectamente, llevo un año con una "memory leak" que me genera errores muy de tiempo en tiempo. El código parece perfecto, sigo las sugerencias del compilador. Al final, va a tener razón el autor: Reescribe el código. Lo malo es que es una jodida clase con muchas propiedades y eventos y me da pereza reescribirla.
#70 te da pereza... Correcto, y encima te considerarás a ti mismo como un buen profesional...
#2 Por favor, insisto en que algún@admin haga algo para que este tipo deje de acosarme.
#2 Es cutre hasta para ser un troll.
#2 En todo caso está generando animadversión hacia Podemos, sicología inversa... y gracias a que le das de comer pues ya tienes tu karma respectivo, como la DEA con el narcotráfico.
#1 Rivera, ¿eres tú?
#1 Venezuela tiene una base chavista en Marte , me lo ha dicho capriles