Archived

This topic is now archived and is closed to further replies.

TroneX

STL & Debugging

Recommended Posts

Alright folks, ... I am not sure how much this topic has been already discussed in here, ... but for the sake of it, let''s add a new thread on this one ... ;-) Let''s assume we have a multimap like this here: std::multimap mmWhatever; Now, in case we have our debugger up and running at some point, we might want to look up, what our multimap looks like. So what do we see? Some incredible bunch of mind dazzling pointers like _Myhead._Left._Parent._Myval ...try to traverse through this and you''ll go totally bananas. So Is there any way to make stl container less painfull and more debuggable? I read that Microsofts implementation of the STL is has been originally adapted from a third party and that it is crap anyway (did not find out why though yet ... except for this debugging problem). Also I read about STLPort which is supposed to be a drop-in replacement for every other implementation of the STL and does furthermore feature a debug mode, .. whatever this means. Does anyone have any experiences with STLPort? I tried to get it working with my VS.NET but it didn''t work. I got it compiled and linked statically to my project, but a part of the LUA remote debugging facility claims, that something doesn''t work then ... Anyway .. have a nice weekend and c''ya later, Chris
LightBrain website relaunched, BomberFUN only USD 9.99
visit http://www.lightbrain.de

Share this post


Link to post
Share on other sites
This is really a huge topic, but hopefully this will clear a bit up:

1) While there are some plugins for vc which attempt to make debugging the contents of a container easier, it will always be messy. I have found steping into the stl code, figuring out how it works internally, and figuring out how to write expressions for it in the watch window to be the best way.

As a side benefit, you learn more about how the containers work if you can wrap your mind around it. (the code tends to be messy as it is highly cross platform).

2) The STLPort debug functionality doesn''t make the internals more viewable; it does things like range checking of iterators. For instance, a vectors operator[] will do range checks just like the .at() does.

3) Microsoft uses stl implementations from DinkumWare. Unfortunately, when VC6 shipped, DinkumWare was in the middle of a legal battel and so an old version (I think from VC4 or something) was shipped with it. The .NET DinkumWare version is modern.

DinkumWare provides a drop in replacement specificly for VC6, so it may be a bit easier to deal with than STLPort, but it does cost a bit of money.

I am cheap and use STLPort, as it has been sufficient for my needs. Getting it up and running was messy IF I wanted to use the modern streams. I don''t think you need to compile it at all for the basic functionality, though it has been a while since I did it.

I know I still haven''t addressed your original about debugging -- maps and other containers which are implemented as trees simply aren''t easy to debug. I wish I had a better answer, but .. I haven''t found one yet.

Share this post


Link to post
Share on other sites