Elgrint::Collection::CIter class

Declared in MVector.h


Generic constant iterator (pseudo-class) of a collection.


Name Description
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.


Name Description
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.


Name Description
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.



Let us know

Please Contact us to report any errors on this page, or to suggest any improvements.

Miranor Home | About Miranor | About Elgrint | Create account | Login | Account settings | Contact Us | Privacy Policy | Site map

© Copyright 2014 by Miranor. All rights reserved. By using this site you agree to the Terms of Use.

Page last updated on August 10th, 2014.