It is slower than direct access via the iterator, but should not be noticeable in a GUI context.
In my case, you are surely right. Inserting/removing items into/from the CListBox is much slower than iterating over the items int the STL list.
However, in this case I could also use a vector. The index of the CListBox would directly correspond to the index of the vector. Although inserting an item in the middle of the vector is no constant time operation, it would not be noticeable within the GUI.
Just curios: Is there any container concept with raw access by index (not by Key) and at least logarithmic insertion/removal time?
The iterator members aren't granted to remain the same, and the iterator itself can be wider than just a pointer (it may have some other members for checkup).
The standard grants that list::itrerator will always be valid until the element they refer remain in the list. An list grants that the element retain their placement in memory until they remain in the list.
Instead of store the iterator, store the pointer to the value the iterator refers to:
You can -at this pioint- access the element directly through the pointer.
Just make sure to update the list and the list-box coherently.
(Note: if *iter has a unary-& overload, just use std::address_of(*iter) )
Thank you for your answer and the interesting article.
However, as I mentioned, I am doing insertions within the middle of the list - so the indices change and it does not make any sense to store them in the data cell.
Additionally: Your article assumes that I would have to find the right insert position and therefore the vector would be faster - but if it would have been possible to store the iterator inside the data cell, I would immediately start at the right position of my linked list.
It would still be nice to have a data structure allowing access by index (not Key!) while beeing able to insert/remove elements in logarithmic time.
I am trying to change the resource data in an EXE file for some reasons. Before I do that, I must get the address of it. But I don't know how to get it. I read some documents of PE. Now I can get the address of IMAGE_RESOURCE_DIRECTORY. Then I open a my-own EXE to do so.
In this EXE, I had added a resource specified by myself. Now I try to change it. In resource-directory structure, the value of RVA of that data is 55E18h. But I can't get the correct address from this RVA. The base address of IMAGE_RESOURCE_DIRECTORY is 4E600h in my EXE. If I add the RVA to the base address, the result address is beyond the file. The correct address of data is 4F418h. I don't know how to get it. Is there somebody be kind to tell me the method? Thx!
There is some white cloud floating on the blue sky. That's the landscape I like.
However, I can't see any sign of them in the final TR1 or C++11. Are they there, but somewhere I've missed? Were they kicked out when the concepts were removed? Will they return if/when concepts do? Who was that masked stranger?
(The correct place to ask this question might be the one of the Boost mailing lists or comp.lang.c++ but I'm not really curious enough to go through the subscription when I can ask here, and I think it's a valid question.)
in my display framework to fire my OnChange method to browser. Using script, I'm setting cancelchange status( window.event.ReturnValue = false; ). But "pfCancelled" argument of FireEvent is not returning cancel status "VARIANT_FALSE". Anybody knows the reason?