Re: [OT] C++ templates and debugging (limitations) in Linux
On Thu, Jan 29, 2009 at 01:47:27PM -0500, "H.S." <hs.samix@gmail.com> was heard to say:
> This is related to templates in C++ and debugging tools we have in Linux
> (I use gdb, is there any other comparable open source tool?).
Not that I know of.
> I recall that a few years ago (a few version of gdb and gcc ago) I was
> having trouble debugging an algorithm I implemented in C++ using
> templates. I do not recall the exact problems but after a few online
> searches it appeared that the easiest way was to not to use templates
> (one problem was that I has having difficulty to examine template
> variables). IIRC, gdb was not very friendly while debugging C++ code
> with templates.
Personally, I almost only use a debugger to get backtraces after a
crash. I find logging statements to be easier, more reliable, and more
useful. If you write cout<< statements directly into your code, of
course, it gets cluttered and unwieldly -- I would suggest taking a look
at a logging framework like log4cxx (available in Debian, even :) ).
That also means that log statements you insert will stick around for
later re-use should you ever have more questions about that bit of the
code.
Why do I find logging statements more useful? Because
(a) you can output information in a way that's useful for you, not
just however the debugger wants to print it (think about, e.g.,
sets stored as binary trees...),
(b) logging statements let you analyze the whole flow of a program
at once -- I once tracked a bug down by running a simple
statistical analysis to calculate which lines were most likely
to precede a crash,
(c) logging statements can be enabled by users and the output sent
to you; much easier than convincing them to install and use a
debugger, and
(d) last but not least, debugger sessions are very ephemeral -- step
too far or let the program exit and you've lost your chance.
Logging statements can be stored and reviewed at leisure,
compared easily between different versions of the program, etc.
The one place where logging fails is when you have some sort of race
condition or another timing-sensitive bug.
Probably a sufficiently complex debugger could emulate that, but why
should I inject a complicated piece of software into my debug process
(injecting also a good chance of bugs in the tool itself), when I can
just write a few log output lines?
Daniel
Reply to: