Portada
mis comunidades
otras secciones
Comunidad destacada de hoy
Tecnología
Tecnología, internet y juegos
#4:
A) Obligar a lavarse las manos antes y después de agarrártela para mear, siempre, en todos lados, a cualquier precio (a no ser que digas "pita alturita", entonces sí, ya puedes hacer lo que te de la gana).
B) Tú decides cuándo y cómo te la agarras, pero la buena costumbre es lavarse las manos al acabar, como mínimo. No es lo mismo una cena con clientes que poniendo ladrillos en la obra (por ejemplo).
Todos sabemos cúal es Rust y cual es C++.
Al final, yo no tengo predilección clara: si quieres hacer programación segura, tienes que aprender unos conceptos y tenerlos claros, ya sea en C++ o en Rust (...que os veo venir: el tooling está mejorando mucho y muy rápido en C++).
B) Tú decides cuándo y cómo te la agarras, pero la buena costumbre es lavarse las manos al acabar, como mínimo. No es lo mismo una cena con clientes que poniendo ladrillos en la obra (por ejemplo).
Todos sabemos cúal es Rust y cual es C++.
Al final, yo no tengo predilección clara: si quieres hacer programación segura, tienes que aprender unos conceptos y tenerlos claros, ya sea en C++ o en Rust (...que os veo venir: el tooling está mejorando mucho y muy rápido en C++).
#10:
¡¡¡Que le den a C++, larga vida a Rust!!!
comentarios. O crea tu cuenta
Comentarios
Mejores hilos
#8 Hablaron los especialitos, que les falta un punto y coma y se les cae el mundo.
#13 los que no sepáis manejar punteros mejor ni habléis
Aclaro, he dicho punteros, no puteros, no vaya a ser que ahora se me den por aludidos millones de meneantes de bien.
expertos en Linux, poco en ortografía.
#0 date el lujo de hacer el titular mejor que ellos con ese "criticó" que nunca llegó. Me la juego a que el acento va ahí.
A) Obligar a lavarse las manos antes y después de agarrártela para mear, siempre, en todos lados, a cualquier precio (a no ser que digas "pita alturita", entonces sí, ya puedes hacer lo que te de la gana).
B) Tú decides cuándo y cómo te la agarras, pero la buena costumbre es lavarse las manos al acabar, como mínimo. No es lo mismo una cena con clientes que poniendo ladrillos en la obra (por ejemplo).
Todos sabemos cúal es Rust y cual es C++.
Al final, yo no tengo predilección clara: si quieres hacer programación segura, tienes que aprender unos conceptos y tenerlos claros, ya sea en C++ o en Rust (...que os veo venir: el tooling está mejorando mucho y muy rápido en C++).
#4 Es lo de siempre: seguro por diseño (cuatro ruedas y eje ancho para mejorar estabilidad) vs seguro porque puedes llevar casco, rodilleras y coderas (aunque al ser sólo dos ruedas es más molón). Si los usas mal, puedes volcar con ambos, pero la facilidad con la que vuelcas también es mayor con uno que con otro... y el estropicio que te haces también.
¡¡¡Que le den a C++, larga vida a Rust!!!
Con mi coche del 1997 si no paso de 50 y voy por carreteras de un solo sentido, es igual se seguro que el coche moderno más sofisticado. ¿Para qué quiero sistemas de seguridad inútiles que nunca voy a utilizar? Lo importante es conducir bien, si no sabes conducir quédate en casa.
#14 pero sin abusar, que algunas librerías de la Boost parecen el códice Voynich.
Todo lo que hace el compilador, ya no tiene que hacerse en tiempo de ejecución.
#2 template metaprogramming
Podría ser justificada la rabieta. En un C++20 ya se puede elegir entre gestión de memoria por conteo de referencias, por puntero único o la gestión tradicional (new-delete).
He visto artículos proponiendo analizadores estáticos que prohíban la gestión de memoria tradicional, lo cual convierte la programación en C++ en algo muy similar a Java.
Si la biblioteca que vas a usar sigue uno de estos sistemas de gestión de memoria, perfecto. Es comodísimo.
Pero hay bibliotecas antiguas que cuando te devuelven un puntero, no te indican de ninguna forma si hay liberar la memoria de dicho puntero o el objeto que te lo devuelve es el que gestiona dicha memoria y en algunos casos es terrorífico averiguarlo.
En mi humilde opinión muchos de estos problemas no serían tan graves si en C o en C++ existiese una palabra reservada para indicar quién debe gestionar la memoria, el objeto que genera el puntero o el objeto que lo va a recibir. Me extraña que en tantos años de existencia de C o C++ nadie lo haya sugerido.
También tiene mucho mérito los métodos que muchos programadores han buscado para realizar la gestión de memoria en estos lenguajes. Por ejemplo, en la biblioteca Qt (C++) se basa en un sistema de padres e hijos. Cada objeto que generes debe tener un padre y a su vez puede tener hijos. Si el padre se elimina, automáticamente se eliminan los hijos.
#41 Es que programar con el palillo en la boca ayuda mucho.
#33 QT "es trampa" (en el sentido de que pasa un kilo de cualquier librería estándar en c++ y se las reimplementa todas), es c++ pero en cierto sentido es su propio c++.
#33 una palabra reservada para indicar quién debe gestionar la memoria, el objeto que genera el puntero o el objeto que lo va a recibir. Me extraña que en tantos años de existencia de C o C++ nadie lo haya sugerido.
Hay algo parecido: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r3-a-raw-pointer-a-t-is-non-owning
Si devuelves un owning ya estás indicando que hay que eliminarlo. Pero creo que todavía no está estandarizado.
No me imagino al creador de un lenguaje reconociendo que otro lenguaje es mejor.
Pero por ahí tiene razón.
#23 normal, está muerta
¿Un buen analizador estático que cumpla con las Directrices principales de C++ puede ayudar a encontrar problemas de seguridad en el código C++. ????? Mi opinión, de experto es que SÍ.
No obstante, hay una objeción: Cambiar a un lenguaje de programación seguro puede proporcionar garantías de seguridad adicionales que un analizador estático no puede proporcionar. Un lenguaje de programación seguro puede tener características diseñadas específicamente para prevenir problemas de seguridad como la inyección de código o la corrupción de memoria, y además, el cambio a un lenguaje de programación seguro puede requerir una inversión significativa en tiempo y recursos, lo que puede ser costoso, no ser rentable.
En resumen, un analizador estático puede ayudar a mejorar la seguridad del código C++, pero cambiar a un lenguaje de programación seguro puede proporcionar garantías adicionales.
Soy experto en IA
Existiendo la encapsulación en clases, existiendo el patrón RAII[1], y existiendo los punteros únicos y compartidos, quién tiene una fuga de memoria en C++ es porque está desactualizado, hace las cosas más, o tiene otros problemas mucho más graves.
[1]: https://es.wikipedia.org/wiki/RAII
Bjarne Stroustrup es dios
Puedes criticar la elección de lenguajes, puedes decir que la seguidad no son solo errores de asignación de memoria, pero intentar vender que un análisis estático en lugar de alabar el trabajo de Rust no tiene nombre.
En parecido orden de cosas, estoy impaciente esperando que muchos trozos del kernel se hagan en Rust, evitando muchos de los errores y posibles vulnerabilidades actuales.
Pues yo con java bastante bien. Besis
Llega tarde a la fiesta. Rust ya ha resuelto el problema.
comentarios destacados