STL Iterator question
For iterating over ranges that you're not supposed to change?
What would the alternative be? const iterator would only work in the limited case where an iterator is an actual pointer type.
What would the alternative be? const iterator would only work in the limited case where an iterator is an actual pointer type.
I think it's a tad more efficient than a normal iterator which is nice if you're not going to change anything as DigitalDelusion said.
Quote:Original post by load_bitmap_file
I think it's a tad more efficient than a normal iterator which is nice if you're not going to change anything as DigitalDelusion said.
The efficeny issue is mostly moot and can be considred somewhat a urban legend of programing but making const correct code makes maintnance easier and works to document the code and put your assumptions into the code instead somewhere burried deep in your skull where co-workers and even you fail to find it 6months later.
Quote:Original post by Telastyn
Why do const_iterator 's exist?
it's to do with constant corrrect-ness, if your doing an operation that does not modify state you should use constant iterators/references etc. Also if you try to do this:
#include <list>struct foo { typedef std::list<int> lints lints bar; //.... void do_it() const { lints::iterator itr = bar.begin(); //whoops, compiler shoot him //.... }}; Your compiler will shoot you unless bar is mutable data member (not generally a good idea unless you genuinely need to modify state in a constant member function) thats when you use constant iterators. Constant iterators will generally contain some form of pointer to constant node or what-ever depends on the container.
Also if you have constant data (or constant reference or pointer to constant data) you can only invoke constant member functions on it hence 2 versions of begin and end both constant and non constant member functions.
Quote:Original post by Telastyn
Why do const_iterator 's exist?
It's the difference between a const pointer and a pointer to const. A const pointer isn't, itself, allowed to change, but the pointee can be modified, while you can make a pointer to const point to different things at different time, but those things cannot, themselves, be modified.
T* const foo → const container::iterator foo;
const T* foo → container::const_iterator foo;
Author
Heh, perhaps being more up to snuff on non-STL constness would help eh?
So it is, in essence, a tool to enable programmers to shackle themselves into not doing something dumb, akin to private class members?
So it is, in essence, a tool to enable programmers to shackle themselves into not doing something dumb, akin to private class members?
Quote:Original post by Telastyn
So it is, in essence, a tool to enable programmers to shackle themselves into not doing something dumb, akin to private class members?
Yes. And constness may have performance implications: the compiler knows that the value isn't going to change.
You'll also need a const_iterator if your container is itself const.
Also its foe when other people read your code (especially maybe if they only see the header files).
Constness does have performance implications. The compilers optimization routines can make certain assumptions about the expressions and statements in regards to refactoring, constant propagation, as well as moving variables into and out of scope to enhance performance. At least from what I understand about compilers and their algorithms. As far as why they exist everyone has chimed in the great answers.
DigitalDelusion: What part of the efficiency of const is moot? Where are the trade offs vs not going const? I'm not attacking you but merely curious.
DigitalDelusion: What part of the efficiency of const is moot? Where are the trade offs vs not going const? I'm not attacking you but merely curious.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
