>I've been reading the arguments for and against linked lists, and I >thought I'd throw my two cents in. I think Rick made a good point about >inserting an item at the beginning of a huge single-chunk of memory. It >might be painful on slow computers to blockmove the huge back-end of the >"chunk" to make room. On the other hand, it may also be painful on slow >computers to find the 955th item of a 1000 item linked list if you have to >walk the whole list just to get there. >What about this...Supposed you combine the two ideas. Make one XREF@ >array where each item is 4 bytes. When you need to create new record >items, create a new handle (or pointer) and store the address in the XREF@ >array at that item number. This way you would have individual records in >memory, but one master XREF@ array of the address to each chunk of memory. > Then if you needed to insert an item into slot #5 of a 1000 item list, >just create your handle (or pointer) and store the address in the master >XREF@ array in slot #5. The most memory you would ever have to move is >4*(the number of following records)....not so bad. Then the other problem >would be solved to. To find item #95, just go to slot #95 in your XREF@ >array to get the address to the handle (or pointer). No need to walk a list. >Makes sense to me. > >Rob Rob, you beat me to the punch. I was just beginning to write that very suggestion when your posting arrived. This is the approach I chose for my current project. If indirection is a good thing, then maybe more indirection is a great thing. Two other points I could make about it: 1) It is easy to create a second (third, etc.) index array in case you want to keep the records sorted in different ways. 2) If you use the index arrays, it may not even be necessary to move all those handles when you delete a record. Just leave it set to 0, and you can plug your next new handle in there. You always need to check for valid handles anyway! It's much quicker to search for an empty slot than to do a blockmove. If there's no empty, just tack the new handle onto the end. (There's even a toolbox call--PTRANDHAND--to do that, although I'm not sure FB supports it.) Your index arrays (which can be _short_ integer XREF@ arrays) will handle the organization. I'm sure there is a speed penalty for additional levels of indirection, but I'm guessing it doesn't even come close to that of big blockmoves. 0"0 =J= a y "