What should be in the documentation.

1. Library structure.
2. General description of the library.
3. For each collection there must be

• detailed description;
• data organization structure;
• in which case it is worth using;
• examples of using.

Add three standard iterator implementations:

• an iterator for collection keys;
• an iterator for collection values;
• an iterator for <key, value> pairs.

The metadata will be organized in a two-tier structure:

• tuple metadata;
• metadata for the element of the tuple as an array.

It should be possible to use for p in List do;

1. Creates heap defragmentation.
2. Return to the heap in which the blocks will be combined from below.
3. Return to the heap in which the blocks will be combined from above.
4. Return to the heap in which the blocks will be both above and below.
5. A situation is created when one more block is required
6. Tests for checking calls with invalid data:

• The address is not from the heap;
• The address is not aligned on the border of two pointers;
• Invalid memory size specified;
• Multiple attempts to return the memory block.

Add iterators to bypass tree elements:

• inorder (from left to right, as the key ascends);
• preorder (from top to bottom);
• postorder (from bottom to top).

1. Insert list item after node
2. Insert a list item before the node
3. Go to the next node
4. Go to the previous node
5. At the top of the list
6. At the end of the list

Hello,

I'm glad to have found this interesting project! I'm trying make some changes to the repository so that it compiles under XE4. I've done several as you can see in the PR #7 , but not sure what to do for the compiler error as you can see in the attached screenshot :) Any help?

1. Flag Owned
2. RangeCheck flag
3. Action to remove an element from the collection:

• clear the item value;
• clear the item value and allow reuse;
• hold the item value.
  Depending on the flag set, we use
  suitable removal method (FreeAndClear, Remove)

4. Notification flag (when inserting, when deleting)
5. Methods for an array
   Get the address of an object by its index
   GetPtr = function (Index: Integer): Pointer;

It should be possible to use for p in List do;

If we have access to the data element via a hashmap iterator via an address, then we can change the key or value, which means that the hashmap will be broken. Subsequent search may become incorrect.
Therefore the iterator should not allow to change the value.

Then we could assume that we have a typed region that contains an array of data described by some tuple.
An easy interface for accessing an array of values would be extremely useful.

var 
  meta: TsgTupleMeta;
  rgn: PMemoryRegion;
  tuple1, tuple2: TsgTuple;
  ptr: Pointer;
  pv: PVector;
  ps: PChar;
  pi: PInteger;
begin  
  meta.MakeTrio<TVector, string, Integer>(nil, True);  
  rgn := meta.MakeTupleRegion;
  tuple1 := rgn[5];
  tuple2 := rgn[7];
  tuple1.Assign(rgn[7]);  
  ptr := tuple.tie(0);
  pi := tuple.tie<TVector>(0);
  ps := tuple.tie<string>(1);
  pv := tuple.tie<Integer>(2);
end;

String repository

Managed data types have a lot of overhead.
This also applies to string type.
I am already coming to the idea that in some places it would be useful to use some kind of repository for strings.
Then we can use PChar instead of a string.

Storing strings in a dictionary is probably a good idea.
Finding a string in a hashmap can be done efficiently.
Most commonly used strings are immutable values.

Typically, strings are used to describe metadata, such as field names, class names, and enumeration values.
When designing a user interface, we deal with a lot of labels.

For example, when we pass data to json, most of this data is field names.
If we use Google protocol buffer, integer encoding without leading zeros is used to encode the fields.

Compression algorithms come with a lot of overhead.

Consider, for example, passing tabular data to display a report.
String data is column names, display styles, width, alignment method, and the values ​​themselves,
which should be for each cell in the table.
It is possible to identify a repeated set of string data for a specific report type with each transmission.
So we can tell you the dataset for report # 9.
Some fields will have a very limited set of values ​​based on the enumerated type.

Permanent string repository.

The immutable part of the data, which may be in each transmission, must be declared as a part of a specific data format and transmitted to the client side once.

Variable string repository.

We pass the modified part as field values ​​or in a separate part of the message.
It is also possible to combine this piece of data with the applicable data and national language encoding.