Re: Debugging STL containers

["Jonathan Wakely" <jwakely dot gcc at gmail 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:

Hi,

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

> I have this preprocessor declaration:
>
> #ifndef _GLIBCXX_DEBUG_MAP
> #include <debug/map.h>
> #define _GLIBCXX_DEBUG_MAP 1
> #endif
>
> Why is there a member in the "__gnu_norm" namespace? Will I ever be
> able to inspect the contents of my maps *at all* using
> __gnu_debug::map? If not, is there an alternative way to inspect the
> contents of libstdc++ STL containers?

I don't think using debug mode containers is the right approach for
what you want.  If anything debug mode makes it harder to inspect
containers in a debugger, because there is an extra level of
indirection that does the extra checking.
The libstdc++ debug mode is *very* useful, but it solves a different problem.

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.  It works pretty well for -O1 -g but at higher optimisation
levels it can get confusing if you don't know gdb's quirks.  Debugging
unoptimised code is usually easier, of course.   One consequence of
this is that you don't need to use a "debug mode" library, full
debugging information can be added to a normal build, with the normal
lib, just by compiling with -g.  However, making use of that
information in a decent debugger is more complicated.  A gdb command
like "print *vec._M_impl._M_begin" usually works but isn't very
user-friendly.

You might find these gdb functions (applied to the normal non-debug
mode containers) helpful (they might need some tweaks for newer GCC
releases)
http://gcc.gnu.org/ml/libstdc++/2007-06/msg00061.html

There are some other tips here:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html

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.

Hope that helps,

Jonathan