LinkedList enhancements

[milan1612]

I request the following linked list functions:

LinkedListSize(LinkedList()) - Retrieve the memory size of the linked list

LinkedListPosition(LinkedList()) - Get the position of the linked list in memory

LoadLinkedList(LinkedList(), Location, Length) - To load a previously dumped linked list

Would be really handy to save complete linked lists and reload them when necessary.
I don't know in how far this is possible already, but I think this set of functions would simplify that a lot.

Milan

[Franky]

I would say, that some possibilitys to get/set the ListHeader would be much better. For me it would be enough, to have that. All the other functions could be written by us.

[milan1612]

I would say, that some possibilitys to get/set the ListHeader would be much better. For me it would be enough, to have that. All the other functions could be written by us.

Aye, but I want to avoid to save/serialize all the entries by myself.
If we had access to the complete list structure including the records
it'd be very easy to save the list e.g to a file.

[Rook Zimbabwe]

If we had access to the complete list structure including the records
it'd be very easy to save the list e.g to a file.

I cannot see how?

I mean you can just create the file and While/Wend to dump it out... Just like an array....

And as for restoring a dumped linked list... dump it into an array before deleting it... Use while/wend to run through it first and count the number if lines... set your array... dump it... then you can undump if you need to.

[Kaeru Gaman]

I'm not sure if it internally works that way that the locations of the listelements are in ANY defined correlation.
hey, it's a LinkedList, each element carries TWO pointers to name it's neightbors.
if they where in defined locations, you would use an Array and spare them two pointers, won't you?

[MrMat]

@milan1612: There is a hacky way to get the s_ data that describes the contents of a list element somewhere in this forum. It's been asked for before but a native way to access this data would be very useful, e.g. to copy lists, clear lists, compare lists, dump/retrieve lists to/from disk, create b-trees/skiplists with support for automatic string freeing, etc. All generic of course so one routine for any structure. Hopefully native access to this s_ data will be added one day since it is all there behind the scenes already and is immensely useful to work with.

[milan1612]

I'm not sure if it internally works that way that the locations of the listelements are in ANY defined correlation.

Of course I assume that all entries are in a contiguous block of memory, otherwise
I'll have no other choice than using the method described by Rook.

[Kaeru Gaman]

just make a test to disprove your assumption:

Code: Select all

NewList Test01.l()

NewList Test02.l()

For n=1 To 3

  pointer = AddElement(Test01())
  Debug "Test01-Element" + Str(n) + ": "+Str(pointer)

  pointer = AddElement(Test01())
  Debug "Test02-Element" + Str(n) + ": "+Str(pointer)

Next

as you can see, the returned pointers are simply ascending, no matter to wich list the element belongs.

in fact, this is the reason WHY you use Linked Lists:
dynamic allocation without the need for fixed location.

if you could deal with fixed location, use an Array.

[milan1612]

Doh!
I ran a test by myself and found that the entries are not in a contiguous order indeed!

Code: Select all

NewList a.l()
NewList b.l()

For i = 1 To 100
  AddElement(b())
  b() = AddElement(a())
  a = i
Next

prev.l
ForEach b()
  Debug Abs(b() - prev)
  prev = b()
Next

It simply debugs the difference between the previous pointer and the current one,
and I get some variations indeed. Okay, then this feature request is kind of undoable?

[Kaeru Gaman]

it is, because of the nature of dynamic allocation.

if you have a LList or something alike, you have to save it recordset by recordset.

if you have an Array or something alike, you can save it as a memory block.