14 meneos
319 clics
Por qué elijo C ++ como lenguaje de programación
Durante muchos años fui feliz como programador principalmente en dos idiomas. Use Python para casi todo y desplácese hasta C cuando realmente necesite el rendimiento.
|
comentarios cerrados
Odio los recolectores de basura. Yo se cuando debo o no debo liberar la memoria.
Antes y ahora.
No ha cambiado nada. Es igual de duro o de fácil que antes.
www.youtube.com/watch?v=i_cVJgIz_Cs
Es igual encontrar información en man que en Google.
De todos modos llevo usando IDES desde el Turbo C y el Turbo Pascal.
El Delphi existe desde 1995, 26 años.
Simplemente debes ser consciente de lo que estas haciendo (y tener cicatrices de pelearte con ellos, claro).
Lo que si es cierto, y es clave ser consciente de ello, es que como se te escape uno vas a sudar tinta...... En C++ es bastante sencillo no tenerlos.
Sinceramente creo que quien diga que es fácil no tener ningún leak en un programa no trivial en C o no ha programado mucho o es un insconciente.
Es cierto que las librerías mal documentadas son un problema.
hacer copias de bloques de memoria por razones varias,
Ahí no hay problema
funciones que tienen que abortar pronto por errores del sistema, etc...
Ahí las excepciones han ayudado mucho. Pero sí, es una de los peores problemas.
Sinceramente creo que quien diga que es fácil no tener ningún leak
Digamos "fácil". No es para tanto como se dice todo el tiempo. Y sigo pensando que el recolector de basura NO es una buena solución.
La mejor solución es programar bien.
Si reservas, liberas.
Y siguen con la mania de los nombres funcionEstupendaQueHaceUnaCosayOtraMasChaChiPirulifnc
Por no hablar de referencias circulares o pasadas a otros componentes, errores lógicos, etc.
En fin, valgrind es popular por algo. Y rust.
No me vas a convencer de que es fácil no tener leaks.
Lo que hablábamos antes: Documentación de las funciones. En la documentación deben decir que "me pasas un buffer dinámico y yo lo libero". De todos modos esa es una mala costumbre.
No me vas a convencer de que es fácil no tener leaks.
No es tan difícil como lo pintais. El problema principal es el uso de librerías de terceros, sobre las que no tienes control.
Si, valgrind es útil. Porque la posibilidad de leaks existe. Pero NO es malo que exista, la alternativa es perder el control sobre el uso de la memoria y la destrucción de los objetos.
xkcd.com/378/
No soy ni capaz de leerlo
Que con coc es un IDE bastante decente
En cuanto tienes alguna función con un switch, o un par de ifs, es facilísimo que se te escape un puntero.
Y cuando se.programa se debe poner MUCHO cuidado.
Es mucho mas fácil y peligroso pasarte del final del área de memoria y no se habla tanto de eso.
vim autocompleta.
Sobre Google, a veces es mierda y lo que es peor, la documentación está desfasada y en vez de solucionar el problema te crea 20 más.
Pero claro, para eso necesitas páginas man decentes, como las de openBSD.
Pero ya ves que aún con unas reglas claras y metódicas, puede escapársete en un punto un mémory leak y ser incapaz de encontrarlo manualmente. Simplemente porque somos humanos.
Si una función "reenvia" ese bloque a todos los efectos es como si lo reservara él, y también hay que tener cuidado.
Que se lo devuelva a la función llamante no es problema.
Los dos primeros puntos requieren MUCHA atención. Dicho eso, bugs lógicos siempre hubo y siempre habrá.
En todos los lenguajes
Como he dicho antes es peor el buffer overflow.
Valgrind y un buen analizador estático es imprescindible (en mi caso tuve que añadir un "simulador" para poder correr el código en el PC y poder pasarle Valgrind, pero desde luego valió la pena).
Por eso hay que poner MUCHO cuidado.
Pero no es ninguna tragedia dadas las ventajas.
CUDA se usa para programar GPUs (y es un superset de C) y no hay matemáticas que vayan a resolver mágicamente la necesidad de paralelismo masivo.
Como lanzar el Octave para resolver (verificar) una ecuación en vez de un CAS como Mathomatic o algo más ligero.