>Ed,
>
>>I'll stand by the statement that this is not something VFP does well -
>
>It really on how "well" is being defined.

"Well" being that I can have lots of list items and traverse the list quickly and efficiently.

>
>> but that the work to implement it
>
>I'd say that work involved, in terms of "amount" of code actually is smaller in VFP than it is in other languages
>

You need to do as much work on the VFP object containing the two pointers and the traversal methods as I would prototyping it by hand in C++; since there are existing list classes in both ATL and MFC, there's "less" work.

>> and the overhead involved, is excessive.
>
>A VFP object definately has a larger memory footprint. I think that's only truly significant when you are talking in terms of thousands of objects though.
>

The resolution of a property to its content, which becomes the pointer to the next object, which contains a property to traverse, etc. is tremendous compared to traversing a pointer in most "pointer friendly" environments, at least IMO.

>VFP's biggest overhead fault is it's interpreter based execution. So if execution time is the prime factor use a C derivative language.

Or Pascal, or LISP, or any of dozens of other "pointer-friendlier" languages. The linked list concept is not strongly supported natively by VFP from my POV.

There's also the issue of storing the list, well outside this discussion; the object address space in VFP is hard to translate into a native storage structure, but much the same can be said of saving lists in a non-linear address space in general; there are OODBMS that are much better suited to this sort of task - Oracle, for example, has a strong Object storage class, and there are specialty database tools like ObjectStore as well.