type command

[Zack]

The Golden Rule: just because something isn't built-it, doesn't mean you can't have it.
I believe the only difference from this and C/C++ pointers is that you need to fit the segment address in there too.
I'm pretty sure POKE in QB translates (roughly) to this (MASM) assembly code:

Code:

QB Code:
DEF SEG=Segment
POKE Address,Value
Assembly code:
mov ax,@data
mov ds,ax
mov DS:[Address],Value

Only difference from C: segments are automatically handled. How else do you think the dereferencer operator ( * ) in C is done? Rather than converting it into a function, C just makes it even more intrinsic, by making it an operator. Same code, though.
Correct me if I'm wrong.

[TheBigBasicQ]

Ahem...look at how pointers really work. It isnt just that C-provides operators to make it more intrinsic.

Try out this program:

Code:

int *p;
int i;

p = &i;

for(<some million times>)
   printf(*p);

Code:

DIM i as INTEGER
DIM p as POINTER
CALL ASSOCIATE_VARIABLE(i, p)

FOR 1 to <some million times>
   PRINT GET_VALUE_AT(p)
NEXT

Do your math to compensate for C/C++ faster execution speed and then tell me which is faster. Now try this:

Code:

DIM i as INTEGER
FOR 1 to <some million times>
   PRINT i
NEXT

And now tell me why would I emulate pointers in QB???

[Zack]

You wouldn't. Just because pset() is available to you, does it mean that you use it? No, you use the POKE method.
With some more math, I think you'd be able to return a TYPE using pointers. I'll have to experiment. If I get that, I'll write a tutorial.

[TheBigBasicQ]

You wouldn't. Just because pset() is available to you, does it mean that you use it? No, you use the POKE method.
With some more math, I think you'd be able to return a TYPE using pointers. I'll have to experiment. If I get that, I'll write a tutorial.

Sure....I will use POKE method in Screen 12 when I am totally out of my mind because POKE is a *lot* slower than the actual PSET command in Screen 12. And dont argue about it because i have actually tried it out.

[Zack]

Jeez, such nitpickery - let me rephrase it:
"Just because pset() is available to you, when you're in SCREEN 13, would you use it? No, you'd use the POKE method."

[TheBigBasicQ]

Still I wont use POKE. I would rather use Rellib =P.

[Zack]

Here we go:

Code:

TYPE ComplexType
   X AS INTEGER
   Y AS INTEGER
END TYPE
DIM ComplexVar AS ComplexType
DEF SEG=VARSEG(ComplexVar)
POKE VARPTR(ComplexVar),10
POKE VARPTR(ComplexVar) + 2,20
DEF SEG
PRINT ComplexVar.X
PRINT ComplexVar.Y

Wow, look at that - we just indirectly accessed members in a TYPE. Using that as a base, it would be very easy to make a function that returns an address of a TYPE. Then make your own couple of functions to deal with dereferencing a little easier, and bingo.
Perhaps I'll make a lib out of it. (read: nobody take this an improve it, because that's what I'm going to do :wink: )

[RST]

I wrote some crap for linked lists before it dawned on me how pointless they would be, given the fact that it's much easier to delcare the types as an array and go from there... :roll: Maybe they could be used for binary tress or some such, but I'll let Zack worry about that.

[Zack]

I could never figure out Linked Lists, even in C (which is generally vaunted as THE linked list language).
This tutorial I'll write will be purely for the use of returning complex variables from functions. Period.