Sign in to follow this  
Magister

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 this post


Link to post
Share on other sites
TheUnbeliever    963
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 this post


Link to post
Share on other sites
ToohrVyk    1595
Quote:
Original post by Magister
why 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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this