Hamlet D'Arcy writes:
> From listening to the conversation about debugging tools, it seems to me
> that the perspective of the list might be skewed. Print statements are great
> when you're debugging your own code or even someone else's code on small
> projects...
>
> But what about those times where you are handed a folder full of files and
> told either "we need this compiled!" or "find the memory leak!". Both of
> these happen to me quite regularly. (And I do realize that this is in a
> C/C++ context, but it could apply to Perl too).
>
> In these situations, an integrated visual debugger is far superior to print
> statements. Sure, you could create log files to reflect a sort of call
> stack, but all too often you will have to add the code yourself rather than
> having the original programmer use debug statements (or such). The same goes
> for listing variables. Want to know the value of every data member in a
> class? I'd prefer clicking the little plus sign and haveing the node expand
> rather than adding a print statement for each member (or set up a
loop).
Sorry, but I have to disagree. Firstly, I don't see how a debugger
(visual or not) is much use with the 2 cases you cited. For memory
leaks there are specialised tools like Purify &
Boundschecker. Commercial and not cheap I know, but can save a lot of
time. (BTW does anyone know of any open source memory leak detection
tools?)
Useful as debuggers are, there are instances where print statements
are the superior tool. If you are debugging code that has to interact
with another process that is not under debugger control, and in a
timely manner, then using a debugger may not be a viable option.
>
> I think an excellent example of a solid, stable, and friendly debugger is
> Metrowerk's Codewarrior's debugger. Call stack, view memory, watches,
> breakpoints, and the ability to alter which lines of code to run... I can
> state from experience that products developed using the Codewarrior Suite
> were brought to market faster and more stable than products developed using
> Borland TurboDebugger or command line tools.
>
> In conclusion, visual integrated debuggers are the best way to quickly
> acquire knowledge of a poorly known program. They give the user faster
> access to data and more debugging control.
If true, then I would be tempted to say poorly designed and written
too. Don't get me wrong, I use visual debuggers and find them very
useful, but they are not the only tools in my toolbox, and they are rarely
the first to be used. Perhaps I'm betraying my age, but I'm with BK on
this one.
--
Brian Raven
P.S. Perl's master plan (or what passes for one) is to take over the
world like English did. Er, *as* English did...
-- Larry Wall in <[EMAIL PROTECTED]>
