>Ed,
>
>>"Well" being that I can have lots of list items and traverse the list quickly and efficiently.
>
>runtime performance: big advantage C++
>

OK - footprint issue - the class that you outlined was a node, not a list; a list would be a container class holding at least one property acting as a pointer to specific node objects; it might contain the node objects themselves, depending on how you defined the class. Without considering that the data structure of a doubly linked list can be expressed more compactly in a linear address environment, where the object 'name' is essentially it's location in the object space, VFP contains the necessary minimum native structure to implement a list - namely, a pointer to an object node, regardless of its type; there is an internal mechanism that resolves these pointers, and the overhead of the resolution in VFP is high compared to many other environments.

>>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.
>
>existing classlibrary: slight advantage C++. No advantage assuming that you already have an equivalent VFP classlibrary that holds these basic advanced data structures.
>

The issue of inheritance of contained objects independently of their container is an issue here. I can have a linked list class in C++ or LISP that can inherit behaviors from both the 'node' class and other parent classes; multiple inheritance, for all the ugliness it can introduce, can offer a strong advantage in terms of derived classes of the list class. Again, the issue can be avoided in VFP by not making the set of nodes and the node address space a part of the list object, but a part of the general objkect space itself, but VFP places constraints on the number of independently named entries in the address space (for those confused, I don't mean specifically the range of addressible RAM, but the number of specified and differentiable addresses of names for the instance of the executing process.)

>>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.
>
>runtime performance: big advantage C++
>
>>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.
>
>We'll just have to agree to disagree here. From the code we have to write standpoint there is no difference, other than language syntactic differences, in the code I write for VFP, C++ or Pascal to manage pointers.
>

Agreed. I like not thinking up how to express concepts like 'head', 'tail' and 'root'. As long as operator overloading is well supported, the traversal code is at the philosophical level equivalent, syntax aside.

VFP does not expect you to put a ";" in the right places - advantage VFP.

>>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,
>
>You can not persist the memory address based pointers in C++ or Pascal. Well, I guess you can if you don't mind lots of C0x memory out of bounds errors when you load the list back into memory. *bg*
>

It's actually easy as long as a part of the linear address can be reserved for restoration of the list, relocatable addresses in storage, or there is an address indirection mechanism (like use of a base register and address relative to the base register.) Not the point, but OK. Without very tight control of the address space, direct reinstantiation of the list is a major PITA.

>>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.
>
>persistence: advantage something other than VFP or C++

That is the point - the right tool!