Vararg in Colletion::ForEach

[HSE]

Hi Biterider!

Can you remind me what problem have vararg in ObjAsm methods?

My big projects still are ObjAsm32, and at some point that could be a problem. In these projects ForEach method is called with vararg.

Thanks in advance, HSE.

[Biterider]

Hi HSE
Sorry for the late replay.

Can you remind me what problem have vararg in ObjAsm methods?

Vararg works in the same way as "invoke". When you declare method in an Object using, for example,

Code Select Expand

VirtualMethod MyMethod, DWORD, DWORD, ?
It means, that you pass 2 DWORDs and a variable number of additional arguments.

When you implemet the method, you have to follow to following syntax

Code Select Expand

Method MyMethod, uses xsi, Arg1:DWORD, Arg2:DWORD, Arg3:Vararg
Arg3 is only used to calculate where the additional args are on the stack. On method entry, eax holds the number of all arguments.

In these projects ForEach method is called with vararg

ForEach and variants use 2 arguments, like wParam and lParam. In most cases this is more than enough, but if not, create a structure on the stack and pass a pointer to it to the iterantor.

Thanks for pointing this out. In the documentation is not mentioned anywhere.

Biterider

[HSE]

Hi Biterider!

Perfect. Then I was having a little confusion 

It's just enough to redefine ForEach.

Thanks, HSE.

[Biterider]

Hi
Using ForEach is not as fast as other coding methods, because you have to take some things into account when writing the code. 
This led me to write experimental macros to make the setup process a bit easier. 
The process starts when you have to deal with more than 2 variables to pass to the callback proc or method. The suggested way to do this is to set up a struct in the stack and pass a pointer to that struct in one of the 2 callback-proc arguments. Theoretically, you don't need the second argument anymore. 

The structure is created with the DefArgs macro, where a Struct-Name and the type of arguments needed are declared. 
To fill the structure before calling ForEach, $FillArgs moves the required values into the structure.
The disadvantage of this approach is the inflexible naming of the structure members (Arg0, Arg1, etc.), which is a bit ugly but gets the job done. 

Perhaps a different approach can be taken by using templates like TVector where the whole thing can be created on the fly...

Attached are the files of a testbed I used to experiment with this concept.

Biterider

[HSE]

Hi Biterider,

This led me to write experimental macros to make the setup process a bit easier.

Look interesting 

The disadvantage of this approach is the inflexible naming of the structure members (Arg0, Arg1, etc.), which is a bit ugly but gets the job done.

That it's not a problem at all:

Code Select Expand

DefArgsName macro StructName, ArgNames:vararg
  $$Count = 0
    for ArgName, <ArgNames>
      @CatStr(StructName,<_Arg>, %$$Count, < textequ >) <ArgName>
      $$Count = $$Count + 1
    endm
endm

DefArgsType macro StructName, ArgTypes:vararg
  $$Count = 0
  StructName struct
    for ArgType, <ArgTypes>
      @CatStr(StructName,<_Arg>, %$$Count, < >, ArgType, < ?>)
      $$Count = $$Count + 1
    endm
  StructName ends
  @CatStr(<P>, StructName, < typedef ptr >, StructName)
endm

$FillArgs macro StructName, LocalVarName, ArgValues:vararg
  $$Count = 0
  for ArgValue, <ArgValues>
    @CatStr(<m2m >, LocalVarName,<.>, StructName,<_Arg>, %$$Count, <, >, ArgValue, <, xdx>)
    $$Count = $$Count + 1
  endm
  exitm <addr LocalVarName>
endm


DefArgsName CALLBACK_ARGS, <Arg40, Arg51, Arg62>
DefArgsType CALLBACK_ARGS, <DWORD, XWORD, BYTE>


Regard, HSE.

[Biterider]

Hi HSE
Thanks for showing this alternative 

Not exactly a Vararg solution, but an alternative for the ForEach loop.
In this case, the macros .ColForEach and .ColNext are used to loop through.

It seems to me a cleaner solution than the previous one, but both have their uses.

Biterider

[HSE]

Thanks for showing this alternative 

It's just the same you posted!

In this case, the macros .ColForEach and .ColNext are used to loop through.

That is efficient 

But, in not so old programs, there is no problem to travel collection' descendents, for example:

Code Select Expand

   OCall _vector::Vector.GetFirst
   .if eax != NULL
      .while eax != NULL
     
         *****

         OCall _vector::Vector.GetNext
      .endw     
   .endif


Code Select Expand

Method Vector.GetFirst, uses xsi
SetObject xsi
.if [xsi].dCount > 0
mov [xsi].dCurrent, 0
ACall xsi.ItemAt, 0
.else
mov xax, NULL
.endif
MethodEnd

Method Vector.GetNext, uses xsi
SetObject xsi
@inicio:
mov xax, [xsi].dCurrent
inc xax
.if [xsi].dCount > xax
inc [xsi].dCurrent
ACall xsi.ItemAt, [xsi].dCurrent
.if xax == NULL
jmp @inicio
.endif
.else
xor xax, xax
.endif
MethodEnd

That can be improved   

Older programs use ForEach

[jj2007]

Code Select Expand

   OCall _vector::Vector.GetFirst
   .if eax != NULL
      .while eax != NULL
     
         *****

         OCall _vector::Vector.GetNext
      .endw     
   .endif


Shorter but equivalent:

Code Select Expand

   OCall _vector::Vector.GetFirst
      .while eax
     
         *****

         OCall _vector::Vector.GetNext
      .endw

[HSE]

Hi JJ,

Shorter but equivalent:

No 

Collection can be empty. Then a lot of problems running "*****" with a null address.

HSE

[jj2007]

You don't need an .if eax if you are using a (rejecting) .While eax loop.

[HSE]

You don't need an .if eax if you are using a (rejecting) .While eax loop.

  I always forgot the jump. Thanks.

[Biterider]

Hi
I have refined the syntax a little and have come to the following result:

Code Select Expand

  xor ecx, ecx
  .ColForEachRev MyColl
    mov xdi, xax
    .ColForEach [xdi]
      DbgDec [xax].$Obj(Primer).pOwner
      inc ecx
    .ColNext
  .ColNext
  DbgDec ecx
That seems intuitive enough to me.
Now .ColForEach(Rev) set up xax directly passing a pointer to the collection item.

I'll add these new macros to Collection.inc.

Biterider

[HSE]

Hi Biterider!

What is ItemReg?

Thanks, HSE.

[Biterider]

Hi HSE
ItemReg in the first incarnation was the register that gets the item pointer. Later I realized that this is not necessary, since I use xax internally and xax keeps this pointer as a byproduct after the ForEach call.

In short, forget it 

Biterider

PS: TVector is another candidate for such macros...

[HSE]

  Thanks.