{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

16-memory-models.student - Last Time Apparent vs Actual...

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

View Full Document Right Arrow Icon
Last Time: * Apparent vs. Actual types * Virtual methods---dispatch on actual type (not apparent) * Separate Interface from Implementation * Pure virtual functions/abstract base classes. Today: * The "big instance" problem * Global/local object lifetimes * A new arena: the "heap". ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Administrative notes: Yahoo Hack-U starts tomorrow. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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, or half of the physical memory on a modern machine.
Background image of page 1

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

View Full Document Right Arrow Icon
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 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 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.
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.

{[ snackBarMessage ]}