Code Templates

[Biterider]

Hi
The use and weaknesses of the Vector Template (TVector) have been the subject of discussion in the threads https://masm32.com/board/index.php?topic=11649.0 and https://masm32.com/board/index.php?topic=11646.0 
In general, code templates are not easy to manage. They are even harder to write to cover all the possible scenarios in which the code might be used.

TVector was born from a single use case. However, it seems that it has evolved and needs to be redesigned to fit better into the overall context.

From the various iterations discussed in the above threads, I was able to consolidate the code and macros and extend the TVector template to a TSortedVector as originally designed by HSE. It now supports REAL4 and REAL8 in addition to the previous BYTE, WORD, DWORD and QWORD types.

One change concerns the .Compare method in TSortedVector, which is no longer an abstract method as in the SortedCollection counterparts, since we are now dealing directly with the data itself.
The sorting direction can be controlled here by reversing the result of the .Compare method.

Some metadata is required for the assembler to generate the code. This is stored in symbols created from the data supplied to the template.
Templates created from other templates inherit this metadata, just like normal objects. This way it is not necessary to supply all the information again, thus avoiding inconsistencies.

Code Select Expand

TVEC_ITEM_TYPE textequ <DWORD>
TVectorName textequ <DwVec>
TVectorID = 125
% include &ObjPath&TVector.inc
TSortedVectorName textequ <SortedDwVec>
TSortedVectorID = 130
AncestorVectorName textequ <DwVec>
% include &ObjPath&TSortedVector.inc
A nice example using the iterator macros I use for my tests looks like this

Code Select Expand

  xor ecx, ecx
  .VecForEach MyVec::PtrVec, dIndex1
    mov xbx, [xax]
    .VecForEach [xbx]::SortedR4Vec, dIndex2
      DbgWriteF ,, "Item[¦UD, ¦UD] = ¦F2", dIndex1, dIndex2, OA_SortedR4Vec_ItemType ptr [xax]
      inc ecx
    .VecNext
    DbgLine
  .VecNext
  DbgWriteF DbgColorString,, "Total count of Items = ¦UD", ecx
Output:

Code Select Expand

Item[0, 0] = 0.10
Item[0, 1] = 0.20
Item[0, 2] = 0.30
Item[0, 3] = 0.40
──────────────────────────────────────────────────────────────────────
Item[1, 0] = 0.10
Item[1, 1] = 0.20
Item[1, 2] = 0.30
Item[1, 3] = 0.40
──────────────────────────────────────────────────────────────────────
Item[2, 0] = 0.10
Item[2, 1] = 0.20
Item[2, 2] = 0.30
Item[2, 3] = 0.40
──────────────────────────────────────────────────────────────────────
Item[3, 0] = 0.10
Item[3, 1] = 0.20
Item[3, 2] = 0.30
Item[3, 3] = 0.40
──────────────────────────────────────────────────────────────────────
Total count of Items = 16
Attached is the testbed I used to verify the vector functionality. 
It may be necessary to update ObjMem.lib as I found a bug in it.

Regards, Biterider

[HSE]

Hi Biterider!

It may be necessary to update ObjMem.lib

TSortedVector.inc it's not necessary? 

HSE

[Biterider]

It may be necessary to update ObjMem.lib

TSortedVector.inc it's not necessary? 
HSE

Hi HSE
You do not need TSortedVector.inc if you do not want sorted data as before.

As I have fixed a bug in the library, it is necessary to update it. The bug concerns udw2decW (32 bit) where only 1 character is returned. In this case eax should return 4, but does not.
In the testbed this is corrupting the DbgWriteF output and cutting off the output prematurely.

Biterider

[HSE]

  Example use TSortedVector.inc, but that is nowhere.

[Biterider]

Hi HSE
You were correct. 
Git did not upload the file for some reason. It needed a "touch" to make it do so. 
You can find the missing file in the attachment as well.

Biterider

[HSE]

Hi Biterider

Perfect 

Thanks, HSE

[HSE]

Hi Biterider,

Why to eliminate duplicated numbers?

Regards, HSE

[Biterider]

Hi HSE
There are 2 reasons that come to mind:
First, I tried to preserve the interface and structure of all containers as much as possible, taking as the master reference "Collection" or "SortedCollection" in this case.
Secondly, I can imagine a situation where you are only interested in the values contained in the vector and not how often they occur.
However, if this is not the case, setting dDuplicates = TRUE will allow these repeated values.

Biterider

[HSE]

Hi Biterider,

I can imagine a situation where you are only interested in the values contained in the vector and not how often they occur.

Good for you

I made the question because I failed to imagine that. What situation?

HSE

[Biterider]

Hi HSE
I can think of 2 situations:

• you are scanning a physical system and collecting data. Your goal is to know what values are possible from that system. In this case you do not need to get the duplicates.
• you are using pointers in your vector and do not want to have the same pointer twice, which would cause problems when you deallocate the pointed to structure more than once.

I suspect you are asking because you have a specific need, right? 
There is no problem from my side to modify the template.

Biterider

[HSE]

Hi Biterider!

I can think of 2 situations:

Ok 

I suspect you are asking because you have a specific need, right?

Mostly the oposite. I just erased checks for duplications.

There is no problem from my side to modify the template.

For compatibility reasons I was thinking could be interesting you allow duplicates by default.

Anyway I'm seeing right now that template could need more "preprocess customization options". Specifically sorting type. In Comparing K-Means and Others Algorithms for Data Clustering in Assembly one vector have ascending order and the other descending order. Originally I add dOrdering switch, but remove code to check that, because was not used. Then could be more optimized if optionally allow duplication check and sorting type at assembling time.

I will make a test how that can be.

Thanks, HSE.

[HSE]

Hi Biterider!

Test with customization have no problems in 64 bits. Obviously is not working in 32 bits.

Regards, HSE.

[Biterider]

Hi HSE
Cool 
This is the idea of a configurable template. If the template works properly, all code flavours are possible.

At the moment I'm working on the super general Vector implementation. 
With this last piece of code, a general rework of the template may be necessary, but the configurability of the TVector features will be included.

Biterider