I have much to do, tons of writing and thinking and course preparation (since I typically want to re-engineer my courses from scratch almost every time, not that I can actually accomplish that goal). I also have too many blogs to read. Every few days I find myself saying, “Oh, heavens, I haven’t even looked at (your name here)’s blog in days. . . .” I have to come to terms with my incapacity to read ’em all daily, and with the likelihood that many will escape my attention for more than a few days.
At the same time, I have to keep on top of the daily obligations. In the next eleven days, I’ll have two adult ed discussions to lead, a an academic talk on the internet and education, and preaching at Leigh Waggoner’s ordination to the priesthood in Eau Claire (no web site for Christ Church Cathedral, somewhat to my surprise). So I have to take my to-do lists extremely seriously for the next few days. No snickering, out there. No matter how interesting your ideas are, my mind will focus fiercely onto the topics at hand — which means that I’ll probably blog a lot while I procrastinate.
Posted by AKMA at April 30, 2003 12:35 PM | TrackBackWhen a variable is finished with it's work, it does not go into retirement, and it is never mentioned again. Variables simply cease to exist, and the thirty-two bits of data that they held is released, so that some other variable may later use them.
Posted by: Lettice at January 12, 2004 11:42 PMFor this program, it was a bit of overkill. It's a lot of overkill, actually. There's usually no need to store integers in the Heap, unless you're making a whole lot of them. But even in this simpler form, it gives us a little bit more flexibility than we had before, in that we can create and destroy variables as we need, without having to worry about the Stack. It also demonstrates a new variable type, the pointer, which you will use extensively throughout your programming. And it is a pattern that is ubiquitous in Cocoa, so it is a pattern you will need to understand, even though Cocoa makes it much more transparent than it is here.
Posted by: Rawsone at January 12, 2004 11:43 PMLet's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Andrew at January 12, 2004 11:43 PMThis back and forth is an important concept to understand in C programming, especially on the Mac's RISC architecture. Almost every variable you work with can be represented in 32 bits of memory: thirty-two 1s and 0s define the data that a simple variable can hold. There are exceptions, like on the new 64-bit G5s and in the 128-bit world of AltiVec
Posted by: Court at January 13, 2004 11:07 AMThis code should compile and run just fine, and you should see no changes in how the program works. So why did we do all of that?
Posted by: Ingram at January 13, 2004 11:07 AMBut variables get one benefit people do not
Posted by: Charles at January 13, 2004 11:07 AM