Strange std::list error

Recommended Posts

Magister    122
ok i had a problem with this but i just switched to <vector> instead now am juust asking out of curiosity [cool]
std::list<DWORD> lVar;

i need to acces an elemnt so i use the irrtator
std::list<DWORD>::irritator it;

This how i comapred the value to something else;
if(it._Ptr->MyVal == SomeVar)
{
//do work
}

in debug mode it compiles and runs no problem but in release mode id does not even compile, the error is unable to access private members of std::list... if you need the exact error i post it here later why is that ?

Share on other sites
The error means what it says. _Ptr is a private member of the iterator (not irritator [grin]), you simply want to dereference the iterator.

if (it->MyVal == SomeVar){  // Do work}

Share on other sites
ToohrVyk    1595
Quote:
 Original post by Magisterwhy is that ?

One of the golden rules in C++ programming is that identifiers which start with an underscore followed by a capital letter are reserved and should not be used, lest unusual and mildly uncomfortable things happen to you.

You used _Ptr, which was public in debug and private in release, so it stopped working. The solution is simple: don't use _Ptr. List iterators provide overloaded operator* and operator->, use these.

Share on other sites
Zahlman    1682
1) It's called an iterator.
2) Whatever you did to find out that there is such a thing as '_Ptr' is something you should not be doing. (Or at least, you should only be doing so with the discipline to ignore what you find out. [wink]) Keep in mind that it's only necessarily present in the standard library implementation that you are using.
3) Switching to <vector> is, by itself, not fixing your problem, in any way, shape or form.. Switching to <vector> "so that you can use raw pointers instead of iterators" is (a) almost certainly shooting yourself in the foot and (b) losing flexibility for, probably, no performance benefit.

You know how those OO advocates are always trying to tell you something about "interface vs. implementation"? This would be one of those issues. The standard library's interface is well known. In particular, all iterator objects provide the interface "behave just like a pointer in every way that makes sense, except that sequential values correspond to elements of the container, rather than memory addresses". The implementation - who knows? The whole point is you don't have to know, and you are wasting your time trying to find out. By not knowing, you enable your compiler vendor to improve things "under the hood" while guaranteeing that your code will still work, without changing a thing.