17-memory-models.student

17-memory-models.student - Last Time: * Separate Interface...

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

View Full Document Right Arrow Icon
Last Time: * Separate Interface from Implementation * Pure virtual functions/abstract base classes. * Structural invariants: must always be true on any method exit Today: * The "big instance" problem * Global/local object lifetimes * A new arena: the "heap". ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ So far, the data structures we've *built* have all had room for "at most N" elements. For example: * the boards in the sorry simulation could have at most 60 squares. * the various IntSet implementations could have at most 100 distinct integers. * the shoe in the blackjack game has room for only one (52-card) deck. Granted, we could have extended these sizes to larger ones, but no matter what we do, so far we only know how to create "static, fixed-sized" structures---we had to declare how big these things could possibly get, and (in the case of IntSet) write code to handle the overflow case. Sometimes, the process you are modeling has a physical limit, which makes a static, fixed-sized structure a reasonable choice. For example, a deck of cards has 52 individual cards in it (not counting jokers), so this is a reasonable limitation. On the other hand, there is no meaningful sense in which a "set of integers" is limited to some particular number of elements. So, no matter how big you make the set's capacity, an application that needs more will eventually come along. Technically, this is not true. If an integer is represented in K bits, there cannot be more than 2^K-1 distinct integers, giving us a maximum set size. However if you declared an array of bool to hold the "largest possible" set of integers on a 32 bit machine, it would 512 MB---and machines typically sell with about 2-4x that much memory, total. For example, consider the list_t type from the second project. The type imposed no limits on how large a list could grow. Of course, the machine would eventually run out of space to store lists, which would cause the program to fail. But, if you run the
Background image of page 1

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

View Full DocumentRight Arrow Icon
same program on a larger machine, it will run longer. It's much cheaper to buy bigger machines than to re-write programs, provided they are not unduly wasteful. As it happens, the list_t implementation was unduly wasteful, but we'll save that for a later lecture. This problem is fundamental to the way we've reserved space for variables so far. There have been two classes of such variables: * global variables Global variables are those defined anywhere outside of a function definition. Space is set aside for these variables before the program begins execution, and is reserved for them until the program completes. This space is reserved at compile time. * local variables Local variables are any variable defined within a block. This includes function arguments, which act as if they were
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

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

Page1 / 8

17-memory-models.student - Last Time: * Separate Interface...

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