This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Debugging STL containers


On 20/02/2008, Joe Buck <Joe.Buck@synopsys.com> wrote:
>
>  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
[snip]
> Agreed; debug mode should not be used with gdb.

I realised it might help Peter if I explained what gdb was showing.
There's no function inlining or optimisation here, gdb is showing you
exactly what the map is: the names and types of all the base classes
and data members in the structure. It's very complicated because
you've chosen the debug mode map, which is a templated wrapper around
the normal map, with even more template specialisations and data
members involved.  When you use a map of maps, that instantiates a lot
of templates.

If you get rid of all the debug mode wrappers and typenames, right in
the middle there is:

_M_header = {_M_color = std::_S_red,
_M_parent = 0x8165d50, _M_left = 0x8165d50, _M_right = 0x8165d50},
_M_node_count = 1}}

This is part of a std::map, it's possible to inspect values manually,
using print and ptype, but the gdb scripts I linked to in my last post
do some of that work for you.
It might help to look at a std::map<int, int> before map<int,map<...>>

>  > 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).

True, it's definitely simpler with unoptimised code.  The more
important aspect which surprises some developers new to gcc and gdb is
you can debug builds with the normal std library, at least for most
templates, and specifically the containers.

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

Sorry. I didn't mean to promote them, only make a comparison, but I
did do it rather badly. I hope the links and other info will encourage
Peter to use gdb, it might take a while to get used to but it's worth
it.

Jonathan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]