I remember that moment of first realization when I figured it out. I remember thinking: oh, THAT's what the peek and poke in Basic way back when were for!
And then coding for PalmOS, which used SysTraps and tons of handles for its API calls, and realizing that they had built tables of pointers that you accessed with other pointers in order to reach the OS functionality--which, looking back on it, was kind of a hack. But a pretty badass hack.
Now, I haven't actually had to put it to practice, so I'm always afraid to say I "get" it.
But at first I was like, yeah so that's what they are. But then I didn't quite get what they were for? I mean ... why can't I just instatiate and go?
Oh right ... because that's what they're for.
It's odd because I actually have a fair number of languages under my belt ... just high level languages that package this stuff for you. I had done C and C++ on a purely API level (where it was already accomplished) and Java (where it's packaged into other objects and new() commands). Now I'm mostly doing C# which is essentially afraid of it.
And the more I read the syntax, the more I think PEEK and POKE might have been a better nomenclature. Going from declaring *varname to using *varname still feels like a doubletake when I read it.
You're missing out. Before all this "OS X" and "DirectX" and "3D Acceleration," pointers were the fun way to get to the screen. Especially in 4-bit color with a rotated buffer.
You could set up your header file to use PEEK and POKE, right? It's been so long since I did that kind of thing. But I did always get mixed up between *variable and &variable. It would have been helpful to have a more human-readable symbol.
That's an interesting idea. At the very least I could write a couple convenience functions to "clean" up some of the syntax. Might be overkill ... or at least an interesting exercise.
Posts
6 comments:
I have a nasty suspicion that most professional programmers don't.
Humorously as I was typing that post - Blogspot refused to respond for a good half hour and I was wondering the exact same thing.
I remember that moment of first realization when I figured it out. I remember thinking: oh, THAT's what the peek and poke in Basic way back when were for!
And then coding for PalmOS, which used SysTraps and tons of handles for its API calls, and realizing that they had built tables of pointers that you accessed with other pointers in order to reach the OS functionality--which, looking back on it, was kind of a hack. But a pretty badass hack.
Now, I haven't actually had to put it to practice, so I'm always afraid to say I "get" it.
But at first I was like, yeah so that's what they are. But then I didn't quite get what they were for? I mean ... why can't I just instatiate and go?
Oh right ... because that's what they're for.
It's odd because I actually have a fair number of languages under my belt ... just high level languages that package this stuff for you. I had done C and C++ on a purely API level (where it was already accomplished) and Java (where it's packaged into other objects and new() commands). Now I'm mostly doing C# which is essentially afraid of it.
And the more I read the syntax, the more I think PEEK and POKE might have been a better nomenclature. Going from declaring *varname to using *varname still feels like a doubletake when I read it.
You're missing out. Before all this "OS X" and "DirectX" and "3D Acceleration," pointers were the fun way to get to the screen. Especially in 4-bit color with a rotated buffer.
You could set up your header file to use PEEK and POKE, right? It's been so long since I did that kind of thing. But I did always get mixed up between *variable and &variable. It would have been helpful to have a more human-readable symbol.
That's an interesting idea. At the very least I could write a couple convenience functions to "clean" up some of the syntax. Might be overkill ... or at least an interesting exercise.
Post a Comment