I should apologize for my tone (I still might).
So first things first - my version of qb64.bas does not contain Idet$ for some reason. But that's irrelevant because a linked list is not just a string, either, so I can't imagine what point you make by directing me there. And the concept does not involve parallel tables or two arrays that need to point to each other. All of that is fluff, all of that misses the forest for the trees.
Let me try to fix things up here for our readers who didn't know...
An classical array is analogous to a pre-hollowed-out space in memory - a manifold if you like - into which you cram data. Even if you can change properties on the fly, such as the total number of elements, this is still a classical array. (Old news.) One assumption we make about storing data that way is the concept of "neighbors". On a rigid manifold, any given element has definite neighbors. You expect array member 4 to be sandwiched between members 3 and 5, so that when we loop through the elements, we hit 3, 4, 5 in order, all the way up to N or whatever. Again, all old news.
The classical array structure has plenty of problems, especially speed problems when the number of elements is large. To do any legwork in the array, we are often looping through the entire list of elements until landing on the right one - sortof like reading through the entire phonebook from the beginning until you find the entry you need... And god forbid you need to make an edit. For a classical array, we need to constantly bump existing elements to make room for the new elements. This is where naive text editors go wrong - if I want to make random edits near the top of a large file, the whole bulk of the text below needs to be jumping up and down the array at an amazing speed, and generates enough lag to kill the project, or to force wonky hacks. Even if computers *do* get fast enough to not notice the problems here, should we really be asking the machine to do all that extra work?
Proponents of linked lists say "no". To understand them is very simple. Throw away the idea of a classical array - the manifold - and thus the notion of "neighbors" goes out the window. There is no notion of jumbling data between bins anymore. To store one unit data in a linked list, you need (at bare minimum) three things:
1) The data itself, such as the letter "F", the number 7, or the whole encyclopedia (for the sake of argument).
2) An address to hold that data. This is just a unique integer that represents each element. Now check this out: In a classical array, these addresses go in linear order. The new idea is that in the linked list scheme, the linearity is not necessary. The data can occupy any unique address at all.
3) A pointing value holding the "next" element's address.
So one node in the list might be ("F",3,7), which stores the letter "F" at address 3, and then points to the next address at 7. This could mean there is some other node ("U",7,19) that stores the letter "U" at address 7, but then points out to 19, and so on. You can have more than one list in the same address space, you can have lists that intersect and merge like a half-zipped zipper or something... You may also violate linearity and create trees this way. Adding, removing, and rearranging elements becomes completely trivial with zero array shuffling.
So in conclusion, I'll admit, I didn't look closely at your code enough to decide if you're actually doing what I described here. If so, then congratulations, you may revert the thread title to what you had originally set.
