EDICIóN GENERAL

[ENG] Microsoft está valorando usar Rust

#1 Los errores de memoria son jodidos de localizar. Por ejemplo, si en una función tienes que liberar la memoria al salir, pero tienes muchos puntos de salida, es fácil que se te olvide liberarla en alguno de ellos. Y encontrar luego donde, es jodido.
#4 #3 tal vez sea un idea loca, pero windows es un producto de software. A lo mejor hasta podemos "pedirle" un poco de calidad a su software.
#7 Es una idea loca, créeme.
El negocio del software no está en el desarrollo; sino en el mantenimiento. La pasta ha estado ahí de toda la vida.
#8. Como con los coches y la revisiones (y reparaciones) en los concesionarios oficiales. Al parecer el coche eléctrico necesita mucho menos mantenimiento lo que explica en parte que se haya tardado tanto en seguir los pasos de la marca Tesla.
(CC #7)
#8 en el desarrollo a medida, puede. En la venta de paquetes software, ni de coña
#4 por eso para ese tipo de cosas se contrata a alguien que sepa y se le paga bien.
#11 Pues buena suerte con esas contrataciones, habra que tener paciencia, porque, por lo menos en este mundo, todavia no ha nacido la persona que es capaz de crear codigo totalmente libre de errores.
#12 Esa persona no ha nacido. Pero a un equipo de personas que Implementan calidad y revisión de pares no se la cuelas.
#13 te falta meter tu mensaje entre tags <ironic>
#13 ¿Te crees que no se escapan errores? Siempre hay cosas que se rompen. Siempre, en Software y en cualquier cosa. O acaso, por ejemplo tu casa no tiene averías? Por poner un ejemplo físico de algo diferente. Pues, en el software ocurre exactamente lo mismo, hay averías, es decir, bugs o incluso errores de fábrica que muchas veces debido a la complejidad son inevitables.
#13 Si, si se la cuelas.
#11 No es ese el problema, un lenguaje de programación en muchos aspectos no deja de ser unas directrices de diseño. Si controlar manualmente la memoria es un quebradero de cabeza, y es más que probable que una persona se equivoque, pues mejor usar directrices que no incluyan ese problema.
#11 la tipica frase cuñadil sobre desarrollo de software
# #11 sí, no hay más que ver que en Google no hay tienen bugs.
#11 ¿De verdad crees que en Microsoft no hay buenos programadores y bien pagados?
#11 Microsoft tiene algunos de los mejores ingenieros del mundo, a los que paga bien y tiene entre algodones. Me quieres decir que les faltas tú o qué?
#4 Por eso una de las recomendacioones es no tener más de un punto de salida de una función, especialmente si vas a trabajar con memoria. Si la función es compleja quizás sea mejor hacer varias en vez de meterlo todo ahí. Sé que no siempre es tan sencillo como lo pintan, pero seguro que ayuda.

En cualquier caso las últimas versiones de C++ han añadido muchas ayudas al control de memoria para poder evitar y, si es necesario, localizar más fácilmente las fugas de memoria y las violaciones de acceso a memoria.
#30 #27 Err..no.
Por un lado tenemos la validacion de parametros recibidos, que cada comprobación puede ser un return en caso de error tras el seteo del error.
Por otro lado una funcion invoca a otras funciones cuyo valor devuelto puede ser un error y se debe terminar a la recepción del mismo la ejecución.
Una función con un "return" solo se ve en la Universidad. En la vida real no existen.
Antes de salir hay que liberar la memoria, o asegurarte de pasar aguas arriba el puntero a la misma (para que lo liberen cuando sea necesario).
El problema de mandarlo aguas arriba es que el programador aguas arriba debe saber que ese puntero recibido debe ser liberado y a veces son dos programadores distintos y se termina leakeando memoria (reservandola pero no liberandola...)
Pero el problema fundamental está en los buffer overflows y buffer overruns. Antiguamente existían funciones para copiar memoria de un sitio a otro, pero era responsabilidad del programador asegurarse que lo que estabas copiando "entraba" en el sitio de destino. De ahí el mítico Malloc para reservar la memoria justa. Pero claro, muchos programadores las usaban y usan incorrectamente, la cadena de origen no cabe en el hueco destino y comienza a escribir machacando datos contiguos en la memoria.
Para solventar esto, se crearon otras funciones de copia de cadenas que te obliga a decir cuantos elementos deben ser copiados. Esto obligaba a los desarrolladores a pensar en el tamaño de la copia, y se reducía el problema del overflow. O peor, el desarrollador pasaba de querer contar y usaba las funciones de copia de cadenas antiguas que no le obligaba a pasar este parámetro.
Los fallos en overflow que he visto...se cuentan por miles...y una razón es que algunas de estas funciones de copia seguras utilizan como parámetro el número de caracteres a copiar, y otras el tamaño en bytes a copiar. Cuando se utilizan cadenas tipo Char, coinciden el numero de bytes con el numero de elementos de la cadena. Pero si utilizas Wchar, el numero de bytes es el doble del numero de elementos dr la cadena.
Si utilizas una funcion de copia para copiar una cadena Wchar con 6 elementos, y resulta que pasas el numero de bytes (12) en vez del numero de caracteres (6) que utiliza el numero de caracteres como parametro....pues estás haciendo un overflow de 6.
Lo mismo pasa con las funciones de lectura, pero aqui basicamente lo que haces es un overrun...es decir...leer 12 caracteres en vez de 6. Leyendo 6 elementos de la memoria contigua que no tiene nada que ver la cadena.
O peor, hacer un underrun, si en una funcion que espera el numero de bytes a leer(12), le pasas el numero de elementos (6). Como se ha pasado 6, entiende que realmente son 6 bytes, 3 elementos. Y te deja 3 sin copiar.
Los underrun son menos peligrosos....y faciles de detectar. Pero los overflow...trackearlos son jodidos....
Ahora ya existen herramientas como Coverity que ayudan bastante en este campo.
#58 En la vida real existen, igual que también existen los casos en que varios return hacen el código más ágil y más eficiente. De todo hay en esta vida.

Y sí, los memory leaks no son lo peor que uno puede encontrarse, especialmente si se trabaja con codigo antiguo, pensado para plataformas concretas que en un hardware más moderno puede dar otros problemas de los que uno a veces no se da cuenta hasta bastante después de tener el código muy avanzado.

Y tal y como comentas, trabajar con cadenas multibyte y unicode en ciertas plataformas puede ser un infierno si no se tiene experiencia, paciencia y tiempo. Y de esto último no suele haber.

Afortunadamente las cosas van evolucionando a mejor y cada vez se cuenta con más y mejores herramientas de trabajo.
#27 Los puntos de salida de una función no tienen nada que ver con la gestión de memoria. Es sólo un tema de legibilidad e incluso hay tendencias que están en contra, favoreciendo el early return.
#61 Early returns si, pero cuando no haya hasta ese punto mucho que liberar y que no haya que andar haciendo muchas IFs para saber que habia o que no habia hasta ese punto. Cuando hay diferentes niveles de recursos adquiridos, goto a etiqueta final y todas las salidas por un punto unico de liberacion de recursos.
#78 Para eso, los programadores de golang tenemos una fantástica instrucción llamada defer. Toda liberación de recursos se incluye en el defer. El defer se ejecutará al salir de la función, por tanto podemos abusar del early return que todo queda limpito.

Ventajas de los lenguajes modernos.
#61 Efectivamente, a eso me refiero, a ficilitar el mantenimiento y la claridad del código. El early return es muy útil cuando está claro y justificado.
#27 Es tan sencillo como usar goto a una parte final comun que libere lo que haga falta.
#77 Te faltó el ironic al final de la frase
#106 No, te equivocas. Hay mucho estigma estupido ( como siempre, muy academico pero poco realista ) con el uso del goto. Si ves eso como ironia, lo siento, pero al menos cierto tipo de desarrollo o ciertos entornos no has tocado.
#4 Con alguna excepción, una función debería tener un único punto de salida.
#4 eso es así con C, con C++ y RAII eso no pasa. A parte hay herramientas como valgrind, que aunque no son la panacea, leaks de memoria como el que mencionas te los pilla.
#32 Ojo, valgrind pilla lo que se de en ejecucion, y muchos leaks, desbordes, etc. ocurren raras veces, vamos, que valgrind te pillara cosas que se reproduzcan facil, pero corner cases...
#79 valgrind pilla los punteros que ya no son accesibles, por eso he dicho que no es la panacea
#85 Si, pero solo pilla cosas cuando se dan ( y si, hara que los que a veces se dan pero no petan, peten ). Pero si hay algo que no se reproduce cuando lo ejecutas con valgrind, pues no lo vas a pillar.
#4 Y en esos casos es donde esta justificado y recomendado usar un goto a un punto final que libera lo que haga falta.

menéame