Nerds log.

Been pondering a lot of stuff.

I've especially been trying to learn more about stacks, queues, lists, and stuff. And it makes me wonder about things we take for granted.

Like arrays for example. How I see an array, at least from a C perspective -- personally I think languages like Ruby. That have arrays that don't need to be 're sized' on command must have implemented arrays in the language. As objects acline to a doubly linked list.

Generally (C like) when I look at an array. I think of it as a pointer and a block. A block of probably contiguous data in memory -- its close together if not physically in hardware then as we may address it from software. And I see the array also as a pointer I can use to reference that block. That points to sections in that block of memory. Where each section is the start & end of a chunk of memory. e.g. the difference between ar[1] and ar[2] is [1] points to the start of the 2nd memory block of the array which is the end of the first. While [2] points to the end of the 2rd but the beginning of the 3rd.

Thus if all memory in an array. Had no padding to note and by incrementing or decrementing the memory address. Our point of reference would advance to the next mark. Sorta. If all addresses were in a fixed range of integers, say 0 - 10. address+1 or address-1 would move our reference to +/- 1 sector of memory. -- Even if the physical hardware doesn't address memory like so, it seems to me by the time we hit software we can run on the machine via an OS / run time it gets this way.

| 0 | 1 | 2 | 3 | 4 |5 | 6 | 7 | 8 | 9 | 10 |

To be honest, I don't know how arrays are implemented. I expect it to be a simple bunch of blocks of memory close together or just a fat segmented block. Where an address reference's marked points of it. In such a way that we have an abstraction in the language that,

for ( i = 0; i < MAXCNT; i++ ) {
do_something( ar[i] );
}

works, gets down to assembly code that makes just as much sense but is more complicated. Then down to hardware that knows what to make of machine code. And down to the physical machine to run it and a realm for electrical engineering or some thing.


When I think about functions. I tend to think of it as a block of memory with all the data it needs, like variables in its scope and what not. and a system of pointers that handle calling and returning. Like

ch = fgetc( fp );

I think it would allocate memory (I hear C is stack based?) for the function (fgetc), use a pointer to fetch that address (call the function). Set the pointer or another pointer or some t hing like that to the return value of the function. Run the code their some how work it out so what the called function returns is what ch contains when references in memory. To me a variable is just a name for a value.

foo = 5;

To me says instead of typing 5 every where, I'd like to be human and just talk about foo instead. And let you (computer) fill in the value the name points to. Or some thing like that any way.

And in a similar light that I'd want to use 'ch' as a reference to the data returned by fgetc(fp) rather then have to know what the freaking location in memory it has !


Ok, so maybe I'm talking out of my ass or maybe I'm getting smarter as time goes on. Who knows...