On Thu, Jan 29, 2009 at 01:47:27PM -0500, "H.S." <hs.sa...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org