22-iterators.student

22-iterators.student - Last time The"not-completely-deep" copy problem containers by reference The"named constructor" idiom clone

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Last time * The "not-completely-deep" copy problem: containers by reference. * The "named constructor" idiom: clone() Today * The Iteration Abstraction * Friends * Observers vs. Mutators +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ So far, we've looked at several different kinds of abstractions: * Functional generalization * Abstract data types * Containers Today, we'll talk about what happens when containers and functional abstraction meet. Several weeks ago, we talked about a collection of abstract data types. We first defined an IntSet, and later defined a subtype of an IntSet, called a MaxIntSet. It was just like an IntSet, with one additional method: int max(); // REQUIRES: set is non-empty // EFFECTS: returns the largest element in set. If you recall, max walked down the set of integers, computing the maximum. While this works, it is unsatisfactory. After all, there are potentially an unlimited number of computations that could be performed on a set of integers. As ADT designers, we have at least two choices. * Predict all of a client's needs, and provide a method for each of them. (Sum, min, max, ...) * Provide an abstraction that can access *each* object in the set, with exactly-once semantics. Obviously, the second is preferable. This is called an "iterative abstraction", or commonly an "iterator" because it allows clients to iterate over the members of some container. In principle, any container class could support an iterator. An iterator is a *separate* abstraction from the container itself. There are two reasons why this is so: * An iterator's lifetime is shorter than its container's: the container must exist before you iterate over its contents, and the container can't be destroyed safely before the iterator is. * A container can have more than one "live" iterator at a time. So, iterators are a *separate* abstract data type. Usually, for each container type one has, there is also (at least) one iterator type defined. An iterator has the following operations: * create: create a new iterator, bound to some particular instance of a container class. Once an iterator is created, the underlying container cannot be modified in any way, else the iterator is invalid. The intuition behind this is that the iterator depends on the...
View Full Document

This note was uploaded on 01/28/2010 for the course EECS 280 taught by Professor Noble during the Winter '08 term at University of Michigan.

Page1 / 7

22-iterators.student - Last time The"not-completely-deep" copy problem containers by reference The"named constructor" idiom clone

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online