|
|
|
Secciones
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Charlas sobre programación con software libre
|
Log in/Crear cuenta
| Top
| 32 comentarios
| Buscar hilo
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Las dos opciones son buenas
(Puntos:1)( http://barrapunto.com/ | Última bitácora: Miércoles, 29 Noviembre de 2006, 23:34h )
Yo creo que lo suyo es hacer buen uso de un depurador y de los "printf" para encontrar la mayor parte de los errores.
Usando solamente un depurador se pueden encontrar muchos errores, pero hay algún tipo de software que se hacen muy difícil de depurar de esta manera: controladores de dispositivos, programas concurrentes... Por ejemplo, los programas con los que hacemos uso de la llamada al sistema fork() solo se puede depurar el código del proceso "padre", pero no el código del proceso "hijo".
Los printf solucionan este problema, pero son poco visuales, sobre todo al tratar estructuras de datos dinámicas. Si usas un depurador como "gdb" con su frontend "ddd" se visualizan todas las estructuras con sus "flechitas" apuntándose unas a otras (tal y como lo dibujaría uno en un papel).
Así pues, yo creo que una cosa no quita a la otra, y a la hora de encontrar esos "bugs" cualquier artimaña es válida.
¿Qué tiene esta bola que a todo el mundo le mola?
Re:Las dos opciones son buenas
(Puntos:0)