debugging C++ when compared to debugging C

Question

HI,

I am normally a C programmer. I do regularly debug C programs on unix environment using tools like gdb,dbx. i have never done debugging of big applications of C++. Is that much different from how we debug in C. theoretically i am quite good in C++ but have never got a chance to debug C++ programs. I am also not sure about what kind of technical problems we face in c++ which will lead a developer to switch on the debugger for finding out the problem. what are the common issues we face in C++ which will make debugger to be started

what are the challenges that a c programmer might face while debugging a C++ program? Is it difficult and complex when compared to C?

Answer 1

GDB can be used to debug C++ as well, so if you have an understanding of how C++ works (and understand problems that can stem from the object-oriented side of things), then you shouldn't have all that much trouble (at least, not much more than you would debugging a C program). I think...

Answer 2

It is basically the same.

Just remember when setting break points manually you need to fully qualify the method name with both the namespace(s) and class (As a resul i someti es find it easier to use line numbers to define break points)

Don't forget that calls to destructors are invisible in the source, but you can still step into them at the end of a block.

Answer 3

Hi Benjamin,

Quite a few issues really, but it also depends on the debugger you are using, its versioning etc:

1. Accessing individual members of templatized class is not easy
2. Exception handling is a problem -- i have seen debuggers doing a better job with setjmp/longjmp
3. Setting breakpoints with something like obj1 == obj2, where these are not POD types may not work

The good thing that I like about debuggers is that to access private/protected class members I don't have to call get routines; just [obj-name].[var-name] is good enough.

Arpan

Answer 4

GDB has had a rocky past with regard to debugging c++. For a while it couldn't efficiently break inside constructors/destructors.

Also stl container were netoriously difficult to inspect in gdb. std::string was painful but generally workable. std::map was so difficult, that I generally added print statements unless there was no other way.

The constructor/destructor problem has been fixed for a few years.

The stl support got fixed in gdb 7.0.

You might still have issues with boost's libraries. I at time had difficulty getting gdb to give me asses to the contents of a shared_ptr.

So I guess debugging your own C++ isn't really that difficult, it's debugging 3rd party classes and template code that could be a problem.

Answer 5

A few minor differences:

When typing a full-qualified symbol such as foo::bar::fum(args) in the gdb shell you have to start with a single quote for gdb to recognize it and calculate completions.

As others have said, library templates expose their internals in the debugger. You can poke around in std::vector pretty easily, but poking through std::map may not be a wise way to spend your time.

The aggressive and abundant inlining common in C++ programs can make a single line of code have seemingly endless steps. Things like shared_ptr can be particularly annoying because every access to the pointer expands inline to the template internals. You never really get to used it.

If you've got a ton of overloaded symbol names, selecting which one you want from the readline completion can be unpleasant. (Which "foo" did you want? All of them? Just these two?)

Answer 6

C++ objects might be sometimes harder to analyze. Also as data is sometimes nested in several classes (across several layers) it might take some time to "unfold" it (as already said by others in this thread). Its hard to generally say so, as it depends very much on C++ features used and programming style and complexity of the problem to analyze (actually that is language independent).

IMO: if someone finds himselfself in the need to debug very often he should reconsider his programming style. Usually for me it is all about error handling at the end. If a program behaves unexpected your error logs should indicate enough information to reconstruct what happened at any stage.

This also gives you the benefit that you can "debug" problems offline later once your program gets shipped to end users.