Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Miles Bader Newsgroups: comp.lang.c++ Subject: Re: Debugger Recommendation Date: Thu, 15 Sep 2011 19:36:51 +0900 Organization: NEC Electronics Lines: 25 Message-ID: References: <4e71c76b$0$24022$a729d347@news.telepac.pt> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net ZIxR4RFLglFLnarqNM+GRwLPJZotGwAc9o7Z9yly/YcHGHPTts Cancel-Lock: sha1:DMjLKf2gq4VvFZ4yH4xf5blgYE4= sha1:hGN1maIRu9bNSAHPEuC7lSnvaAk= System-Type: x86_64-unknown-linux-gnu Blat: Foop Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:10160 Rui Maciel writes: > Sometimes a program simply behaves unexpectedly, and a programmer is > therefore faced with the need to run a program step by step, > evaluating the outcome of each step, to be able to understand what > is happening and why is it happening. Unit checks don't do this, > neither does valgrind. Without a debugger, all you end up having is > a nasty cycle of sprinkling your code with cout/cerr, recompiling it > and running the program to analyze the output of your set of > cout/cerr. But the converse is also true: people often over-rely on debuggers, and spent huge amounts of time stepping and examining, when a different tool / technique would find the problem much more quickly. As with most things, the balance lies somewhere in the middle: sometimes a debugger is the best tool for a debugging task, at other times valgrind-type tools are, and sometimes "printf debugging" is the right thing. A good programmer can use all of these techniques, and has an intuition as to when each is called for. -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche