Hi,

I sent this contribution to this thread several days ago while my ISP was messed up. I can't tell that it was received, so here it is again. Please excuse if you've already seen this:
======================
Subject:     Re: [FB] FN RESERROR
Sent:        11/24/98 3:19 PM
To:          FB list, futurebasic@...

>However. I never use XREF, not it's @ cousin, as they seem too
>much fuss. What's wrong with grwowing your own handles, then you
>can check, length and overwriting, and you know where you are?
>XREF just seems a level of indirection that can create confusion
>and error... As this original post would imply...
>
>jonathan
>
I respectfully disagree. XREF@ adds structure, not indirection. It's simply the elegant way of doing exactly what you are suggesting. Granted, you still have to do the checking, but you have to do that in any case.

Essentially, what the XREF statements do is allow you to use FB's robust array-handling routines on memory that you specify, rather than on memory that you explicitly allocate with a DIM array(10,20) statement. It eliminates the need to pass (i.e., copy) arrays between functions, because you can just pass their handles (or pointers).

I'd bet an icecream cone (2 scoops!) that for regular-length data (%, &, etc., or records), my XREF@ code will be shorter and probably more elegant than your "home-grown" handle code.

¢¢

 0"0
 =J= a  y
  "             (more below)
===============================

>I define a record...
>DIM RECORD testRec
> DIM testFirstEntry%
> DIM testSecondEntry&
> DIM 25 testThirdEntry$
>DIM END RECORD.testRec
>
>Then I use ( 3*_testRec + _testThirdEntry) type constructions
>the put and get the info in the handle. This seems as intuitive
>as I need. I'm not saying XREFs is not good, just that they
>seem to create confusion (would they be a hangover from a
>time when there was no support for handles and pointers in FB?)
>and thus I have never perceived that the gain I could obtain
>from using them would exceed the investment in time and grey
>matter to grok and debug the little thingies (This is of course
>a reflection on the bad quality of my grey matter, not on XREF,
>but my point was that if others have similar 'conceptual' problems
>with XREF, there are other techniques...)
>
>jonathan

And if you need 1000 entries? I know you're not short on gray matter, but maybe you need a primer:

You understand arrays, yes?
You understand handles and pointers, yes?

XREF and XREF@ merely put arrays into pointers and handles, respectively.

To use XREF@,

'1. Set up variables to hold handles
  DIM myXArray&, myHandle&

'2. Allocate some space for the array. Let's assume 100 Long integers,
'   so the size needs to be 100*4 = 400
  myHandle& = FN NEWHANDLE(400) 'You would do this to grow your own anyway

'3. Dimension the array using XREF@ (exactly like a DIM statement)
  XREF@ myXArray&(99)  'Use same name, so FB knows which handle to use

'4. Tell FB where to find the array
  myXArray& = myHandle&

You're done! myXArray&(n) is exactly like any other array you've ever DIMmed, except that it is located at [myXArray&].   (Which is also [myHandle&].)

What may get confusing is that if you want to use another (_any_ other) array of long integers in a handle, you can do so just by providing the handle:
  myXArray& = myOtherHandle&
This is the equivalent of BLOCKMOVEing one array into the space of another, except nothing has to be moved except the handle, and the original array isn't demolished in the process.

When you "grow your own," you're duplicating functions that are available in FB, and which have been tested and proven a lot more than yours.

I hope this adds more clarity than confusion.
 0"0
 =J= a  y
  "