Re: Debugging STL containers

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On 20/02/2008, Peter Geoghegan wrote:
> > I'm a C++ developer with an MS windows background, developing a G++
> > application on Linux which makes extensive use of the STL. There are
> > many nested templates in this application. I'd like to be able to
> > inspect the contents of the container in debug mode, as in visual
> > studio. Using <debug/map> rather then <map> looked promising. However,
> > due, presumably, to inlining and other optimisations, the value of the
> > maps are still resolved to things like:

On Wed, Feb 20, 2008 at 10:17:27PM +0000, Jonathan Wakely wrote:
> The debug mode isn't intended to help visualise containers, rather it
> does extra runtime checking of preconditions such as iterator
> validity.  It's what is sometimes referred to as a "checked STL".
> It's documented here:
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html

Agreed; debug mode should not be used with gdb.

> With g++ and gdb you can still debug optimised code i.e. it's not
> necessary (as I believe it is with VC++) to have a separate build to
> debug it.

Unfortunately, though, any optimization will make basic member
functions like size() disappear (if they are inlined, they can't
be called from gdb).

> Kdevelop and DDD are two graphical front-ends for gdb, but don't
> expect Visual Studio. Many developers used to Visual Studio are
> horrified at the poor GUI debugging support for GNU/Linux.  A debugger
> is the one commercial software product I'm considering buying for my
> personal development, because the current open source debuggers aren't
> great for C++.  There are a few non-Free debuggers available for
> unix-like systems but it would probably be off-topic to discuss them
> here.

Not just probably; promoting proprietary software on an FSF list
is definitely out of bounds.

But it would be nice if frustrated developers would contribute to
making gdb and the graphical front ends better.  As a first cut,
having gdb understand the standard classes would be cool.  Certainly
proprietary systems can be a source of ideas, assuming patents aren't
an issue.