lecture16 - Last Time: * Representation Invariants...

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

View Full Document Right Arrow Icon
Last Time: * Representation Invariants revisited * Checking repInvars explicitly * Defensive programming Today: * * * * Checking, continued 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 monopoly simulation could have at most 40 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. For example, consider the list_t type from the second project. type imposed no limits on how large a list could grow. The 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
Background image of page 1

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

View Full DocumentRight Arrow Icon
reserved for them until the program completes. is reserved at compile time. This space * local variables Local variables are any variable defined within a block. This includes function arguments, which act as if they were defined in the outermost block of the function. Space is set aside for these variables when the relevant block is entered, and is reserved for them until the block is exited. This space is reserved at run time, but the size is known to the compiler. Since the compiler must know how big all of these will be, it is static information, and must be declared by the programmer. ++++++++++++++++++++++++++++++++++++++ It turns out that there is a third type of object you can create, a "dynamic" one. They are dynamic in the sense that the compiler: * doesn't need to know how big it is. * doesn't need to know how long it lives. For example: * our implementation of IntSet should be able to grow as big as any client needs it to grow, subject to the limits of the physical machine. * the IntSet should last as long as the client needs to use it, after which the *client* should be the one responsible for destroying it. This is accomplished through the dynamic storage management facilities in the
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 04/04/2008 for the course EECS 215 taught by Professor Phillips during the Winter '08 term at University of Michigan.

Page1 / 13

lecture16 - Last Time: * Representation Invariants...

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