AKMA’s Random Thoughts

"Well, we've never actually met, but s/he's going through some stuff right now, so I'm kind of trying to help..."

I've acquired quite a few of these lately.

Remember, a stranger is just a friend you haven't yet met.

I know we're friends. We comment in each other's blogs.

As a Friend, that is a member of the Religious Society of Friends, a discussion of defining friends or Friends is quite interesting. We frequuently refer to friends with the capital "F" or friends in the small "f"sense. I have plenty of friends who are also Friends, and I have plenty of friends who are not Friends. So, I am always a Friend, even if I am not a friend or even friendly.
Which leads to a question, can one be a friendless Friend?

"Hey, friend, when will you quit your debts with me?"

Fishrush,
A friend have not yet met, turned me on to this comments thread. Very friendly, I must say. Got a Ryze out of me.

I like those commenting subsystems that let you edit your own comments. I remember why I laid in a comment here in the first place and it would be simply twee if I could update the first one instead of adding this: anyone, my Friendly thought related to the weird observation in the posting: "The enemy of my enemy is my friend." I've heard this before and always ask when possible,in as friendly a way as possible: if you have enemies, how can you have friends?

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.

Each Stack Frame represents a function. The bottom frame is always the main function, and the frames above it are the other functions that main calls. At any given time, the stack can show you the path your code has taken to get to where it is. The top frame represents the function the code is currently executing, and the frame below it is the function that called the current function, and the frame below that represents the function that called the function that called the current function, and so on all the way down to main, which is the starting point of any C program.

Our next line looks familiar, except it starts with an asterisk. Again, we're using the star operator, and noting that this variable we're working with is a pointer. If we didn't, the computer would try to put the results of the right hand side of this statement (which evaluates to 6) into the pointer, overriding the value we need in the pointer, which is an address. This way, the computer knows to put the data not in the pointer, but into the place the pointer points to, which is in the Heap. So after this line, our int is living happily in the Heap, storing a value of 6, and our pointer tells us where that data is living.

This 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?

When the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.

But some variables are immortal. These variables are declared outside of blocks, outside of functions. Since they don't have a block to exist in they are called global variables (as opposed to local variables), because they exist in all blocks, everywhere, and they never go out of scope. Although powerful, these kinds of variables are generally frowned upon because they encourage bad program design.