>>I don't think that there's anything particularly difficult about it's implementation. It's pretty much of a universal construct in the higher level languages implemented on a PC (Pascal, C, C++, MS Basic at least as far back as QB3, Modula 2, etc.). Rather it may be a matter of utility. Since VFP plays around with its internal memory allocation so much, pointers would be extremely difficult to implement, so they might cause a problem, which in turn further limits the utility. However, of the top of my head, I can think of a bunch of structures required by API calls that don't involve pointers, and the structures are simply a section of contiguous memory.
>
>The problem is pointers and the storage of strings (the only thing usable in VFP to create structures); VFP's loose typing requires multiple indirections of storage references via something called the NTI, and during VFP's memory management, storage is often rearranged, with the net result that any pointer created prior to the reshuffling is probably invalid. As a result, there's no 'simple' method of creating and maintaining a structure in fixed locations in VFP-managed memory - that's where something like CLSHeap or STRUCT come into play; both allocate blocks of memory not managed by VFP's manager, and can then return pointers to these blocks safely (as integers).

There's still no reason that VFP couldn't give us a structure type and manage the string construction/deconstruction for us. I know that I can use the Struct class for this, but that often feels like hitting a fly with a sledge hammer. As long as the Structure doesn't contain pointers (many dont), VFP's memory management shouldn't be a problem. A structure could be treated exactly like an object.

While they're at it, could they also make VFP read a C header file? :-)