Skip to main content
gamedev.net
🔒 Locked

Debugging STL vectors

Started by PyroBoy Jan 16, 2002 at 4:56 PM 17 replies 550+ views
Original Post
PyroBoy
PyroBoy
This is an issue that''s been bugging me for a while. Maybe someone on here has figured it out... How do you display a specific element of an STL vector object inside the VC++ debug "watch" window? If you type something like myVector[5], it''ll say "Overloaded operator not found". You can see the first element via the first() function, but other than that... This is a major pain when you''re trying to debug lists of objects inside vectors. How do you make vc++ display this stuff in debug?
Oluseyi
Oluseyi
quote:
Original post by PyroBoy
How do you make vc++ display this stuff in debug?

I think I''ve done it once - and only once. The syntax was so convoluted that I simply decided to access/iterate through the values and place it in a separate variable which I could place in the watch window.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
Shannon Barber
Shannon Barber
suck the iterator into a local and watch what the local iterator points at
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
PyroBoy
PyroBoy
You''re kidding! Ouch.

All they''d need is something like a GetElement(index) function that works just like [] without the overloaded operators, and I suspect a lot of people would be much happier with STL vectors. I know I would be.

PyroBoy
PyroBoy
Magmai >> how''s that done?

Oluseyi
Oluseyi

vector<your_type>::iterator iter, stop = v.end();
your_type local;
for(iter = v.begin(); iter != stop; ++iter)
{
local = *iter;
}

Put local in the watch window.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
PyroBoy
PyroBoy
Good idea!
That still seems like too much fuss just to look at some values. Oh well. No other way I guess.

Oluseyi
Oluseyi
AP: absolutely cool!
Stoffel
Stoffel
I knew about the ._First[4], but I didn''t know about the ._First,10. I''ll have to start using that. Thanks, AP.
DrPizza
DrPizza
All the STL implementations I use have std::vector::at(), which should do precisely what you need; they take a single parameter as an offset, and I think they throw an exception if your offset is invalid.

I don''t know if it''s actually standard.


char a[99999],*p=a;int main(int c,char**V){char*v=c>0?1[V]:(char*)V;if(c>=0)for(;*v&&93!=*v;){62==*v&&++p||60==*v&&--p||43==*v&&++*p||45==*v&&--*p||44==*v&&(*p=getchar())||46==*v&&putchar(*p)||91==*v&&(*p&&main(0,(char**)(--v+2))||(v=(char*)main(-1,(char**)++v)-1));++v;}else for(c=1;c;c+=(91==*v)-(93==*v),++v);return(int)v;} /*** drpizza@battleaxe.net ***/
PyroBoy
PyroBoy
Hot damn!! _First() works like a charm. Thanks AP!!

I tried at(), but got "symbol is ambiguous". Maybe there''s a few overloaded versions?

Can''t find _First() or any flavour of at() in the documentation. I tell ya, the more I program these days the more I find that incomplete or misleading documentation for APIs or libraries is one of the biggest pissoffs I encounter, and certainly accounts for the most wasted time and effort.

meh, still quicker than writing from scratch! :-)
Kylotan
Kylotan
PyroBoy, they can''t change the STL just because of the inadequacies of Visual C++

_First() isn''t documented because that''s an implementation specific. at() is documented everywhere that I''ve looked. The docs here match those that came with MSVC 5 and 6. Click on the ''at'' link. The MSVC documentation is pretty poor, but it''s comprehensive. (ie. There''s enough there so that you can pick out keywords to look up elsewhere )

And it seems like almost any STL construct debugged in MSVC produces ambiguous symbol errors. Grr.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
Stoffel
Stoffel
quote:
Original post by Kylotan
And it seems like almost any STL construct debugged in MSVC produces ambiguous symbol errors. Grr.


This is, of course, due to the infamous "symbol longer than 255 characters" warning. Any symbol longer than this (and just about anything in STL is) can''t be debugged. Gotta love it.
Kylotan
Kylotan
In a world of MS bloatware, they pick the most inopportune place to save space by limiting strings to 255 characters, don''t they?
PyroBoy
PyroBoy
>>_First() isn''t documented because that''s an implementation specific.

hmm true enough

>>at() is documented everywhere that I''ve looked.

I use the sgi docs, and they don''t mention at(). It''s listed on that MS link though. Good stuff.

Kylotan
Kylotan
You''re right, Pyroboy. It is in their library, though:
#ifdef __STL_THROW_RANGE_ERRORS
void _M_range_check(size_type __n) const {
if (__n >= this->size())
__stl_throw_range_error("vector");
}

reference at(size_type __n)
{ _M_range_check(__n); return (*this)[__n]; }
const_reference at(size_type __n) const
{ _M_range_check(__n); return (*this)[__n]; }
#endif /* __STL_THROW_RANGE_ERRORS */


[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
null_pointer
null_pointer
SGI STL is not the C++ standard library. It is basically a work-in-progress by Andrew Koenig (sp?), who wrote the original STL that became the C++ standard library. Therefore, you will find some things in SGI STL that behave differently than in the standard library. To compound the problem, MSVC uses an older version of the standard library (provided by Dinkumware), so you have three different versions going here (MSVC STL -> standard library -> SGI STL). And as has already been noted, MSVC has poor support for templates.

MSVC has a good, if somewhat dated reference. Pop in your MSDN CD and look up the "Visual C++ Documentation," / "Reference" / "C++ Language and C++ Libraries" / "Standard C++ Language Reference." It''s in there. If you have trouble finding it, type in "vector" in the index, locate the proper page, and hit the Windows'' Help "Locate" button to reveal where in the library it is located.
null_pointer
null_pointer
quote:
Original post by PyroBoy

>>_First() isn''t documented because that''s an implementation specific.

hmm true enough


Names with leading underscores are reserved for use by the C++ implementation. When you see them, red flags should go off in your mind. But they can prove useful...

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.