AKMA’s Random Thoughts

There's something about postmodernism that disturbs me a lot and the subject is very difficult for me to comprehend. I think I am beginning to grasp certain distinctions however, and I of course meant no personal offense in my blog posting.

I encounter postmodernist inspired change agents in my community every day, and I have to say that their inability to express reasons for the changes they seek, and the fact that the changes are an earthquake rocking our very foundations has inspired my search for an understanding of that which motivates them.

Most importantly, I address your blogging with love and respect, even if my posting should appear to challenge your work. Obviously, I am merely dipping a tentative toe into this ocean of thought that has informed your career. I hope you can offer some guidance and reflection from time to time to help me understand the shape of postmodernism better. (I also understand that you are paid for this work, and it's importunate at best for me to solicit a freebie).

I fat fingered it this morning and deleted the offending post by accident... but perhaps there are no accidents and I certainly felt like I had done something for the good of all blogkind. The pixels have faded but the ideas haven't died. I'll look for a less challenging way to express those thoughts again and hope I can get your professional reflection on my perspective then.

Ummm yes. The more I think about pulling that post the more I am convinced I was channeling Ozymandias.

When compared to the Stack, the Heap is a simple thing to understand. All the memory that's left over is "in the Heap" (excepting some special cases and some reserve). There is little structure, but in return for this freedom of movement you must create and destroy any boundaries you need. And it is always possible that the heap might simply not have enough space for you.

That gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.

Let'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.

To address this issue, we turn to the second place to put variables, which is called the Heap. If you think of the Stack as a high-rise apartment building somewhere, variables as tenets and each level building atop the one before it, then the Heap is the suburban sprawl, every citizen finding a space for herself, each lot a different size and locations that can't be readily predictable. For all the simplicity offered by the Stack, the Heap seems positively chaotic, but the reality is that each just obeys its own rules.

The rest of our conversion follows a similar vein. Instead of going through line by line, let's just compare end results: when the transition is complete, the code that used to read:

This is another function provided for dealing with the heap. After you've created some space in the Heap, it's yours until you let go of it. When your program is done using it, you have to explicitly tell the computer that you don't need it anymore or the computer will save it for your future use (or until your program quits, when it knows you won't be needing the memory anymore). The call to simply tells the computer that you had this space, but you're done and the memory can be freed for use by something else later on.