Declared in MVector.h
Generic constant iterator (pseudo-class) of a collection.
|CIter()||Default constructor. Creates an invalid iterator, not owned by any collection.|
|CIter(it)||Copy constructor. Creates a copy of an iterator of the same type.|
|CIter(c)||Init constructor. Creates an iterator and points it to the beginning of the specified collection.|
|~CIter()||Destructor. Similar to reset.|
|operator++()||Moves the iterator to the next item in the owner collection.|
|operator=(it)||Assignment operator. Copies one iterator into another of the same type.|
|reset()||Invalidates and disowns the iterator.|
|operator!=(it)||The logical opposite of operator==.|
|operator()()||Validity check. Returns true iff iterator is valid.|
|operator*()||Dereferences a valid iterator. Returns a reference to the item the iterator points to.|
|operator==(it)||Returns true iff two iterators point to the same item.|
Even though iterators of each collection are different, all share the same 11 common methods, as if they are all derived from this CIter pseudo-class.
Iterators are needed because they are typically more efficient and more universal than collection's specific revealers, while being practically as safe. In DEBUG mode iterators are perfectly safe (unless you hack them on purpose, of course), and reasonably safe even in RELEASE mode.
If an iterator points to a collection, it is said to be "owned" by that collection. The collection is aware of all the iterators it owns, thus making iterators as safe as they are, because collections adjust (revalidate or invalidate) iterators owned by them on any change to the collection. See collections' mutators for more information.
This owning mechanism prevents most safety issues of iterators. For example, if an iterator points to an item and this item is removed, the iterator automatically "jumps" to the next item if possible, or invalidated otherwise. This prevents the problem of dangling iterators.
This safety mechanism does not affect the efficiency of the iteration process, but it does affect the efficiency of iterator's creation and destruction. Therefore, the iterators should only be created when necessary. As a rule of thumb, if a collection contains less than 10 small items, an iterator may not be the most efficient choice.
The owning mechanism also affects the efficiency of collections' mutators, so it is recommended to reset iterators before modifying the collection that owns these iterators. There is virtually no performance penalty due to this owning mechanism, if there are no owned iterators present.
- A collection can own any number of iterators at the same time (both constant and non-constant), but it is rarely necessary to have more than one or two
- All collections have constant iterators except for MString, because MString::operator is just as efficient as an iterator, and safer too
Let us know
Please Contact us to report any errors on this page, or to suggest any improvements.