String comparing issue

[hutch--]

Nilrem,

Hutch the problem arises if I have one string called Thunder and another Thunder2.

All tis means is the algo you are using is not doing the comparison properly for the string length. You only need to pass the length of one string, usually the first one and then do the comparison and you should pick if one is different in its last character than another.

[Nilrem]

What I'm saying is I have the following

invoke strcmp, offset lpDropDown, offset ThunderPopper, 13

so if ThunderPopperII is selected from the dropdownmenu then when the above happens it will think ThunderPopper is selected when in fact ThunderPopperII is, but I cannot fix this problem because changing 13 to 15 results in if ThunderPopper is selected then it doesn't come up when it should.

I just either had to put strcmp ThunderPopperII before strcmp ThunderPopper
but I like it to be in order (my code) so instead I used szCmp.

[Mark Jones]

Implement Hutch's idea. It would be great practice, plus be very fast.

[Nilrem]

I have implemented his, but it doesn't work if I have this:

Code Select Expand


invoke strcmp, offset lpdropdown, offset thunderpopper, 13
jnz @f
ret
@@:
invoke strcmp, offset lpdropdown, offset thunderpopperII, 15
jnz @f
ret


That doesn't work if the string ThunderpopperII is selected because it stops at the first strcmp because the first 13 bytes of thunderpopperII matches the compare.

[tenkey]

You need to pass the lengths of both strings. You need to know if the strings differ in length or not.

[hutch--]

There is something fundamentally wrong with the premises here, if the strings are zero terminated, it does not mater if they are the same up near the end or not, the difference is measured with the zero terminator included.

Code Select Expand


"string",0
"string1",0


A single coparison algo will exit when the "1" is compared with the terminating zero as a mismatch.

[Mark Jones]

Check out this little snippet I made while up coding late. Very late. :)

Code Select Expand


SzComp  proc    sz1:DWORD, sz2:DWORD
    mov esi, sz1            ; load string offsets
    mov edi, sz2
    cld                     ; clear direction flag
@@:   
    cmpsb                   ; compare bytes esi,edi
    jne err                 ; different?
    cmp byte ptr [esi-1], 00  ; is one a null?   
    jz eos                  ; yes, strings match
    jmp @B
err:
    mov eax,1               ; compare failed
    ret
eos:
    mov eax,0               ; compare succeeded
    ret
SzComp endp


[Nilrem]

Hutch what is wrong is ThunderPopper gets compared before ThunderPopperII

So if I have this

invoke strcmp, offset lpdropdown, offset thunderpopper, 13
jnz @f
code

@@:
invoke strcmp, offset lpdropdown, offset thunderpopperII, 15
jnz @f
code

As you can see if ThunderPopperII is in lpdropdown then at this point:

invoke strcmp, offset lpdropdown, offset thunderpopper, 13

only the first 13 bytes get compared and hence therefore it thinks ThunderPopper is in lpdropdown. What I should have done is tried and edited your algorithim you wrote Hutch so that when the comparison has finished, and it thinks it is successful I should then check to see if there is any remaining bytes, however whilst writing this I have realised that wouldn't work because I already specified 13 bytes. I think I'll look at szCmp and see the differences.
Mark Jones thanks for the late night coding effort, I'll try it later today hopefully.

[Mark Jones]

Whoa nellie, my string compare is tons faster than lstrcmp, see the attached project:

Code Select Expand


SzCmp/lstrcmp speed comparison by Mark Jones (gzscuqn02ATsneakemailD0Tcom)
Timing routines by MichaelW from MASM32 forums: http://www.masmforum.com/
Please terminate any high-priority tasks and press ENTER to begin.

These are the three 64-byte strings being tested:
"Hello, this is an example of a MASM32 64-byte string comparison."
"Hello, this is an example of a MASM32 64-byte string comparison!"
"hello, this is an example of a MASM32 64-byte string comparison."

Timing results:

SzCmp, 64 bytes identical string: 416 clocks
SzCmp, 64 bytes different string (last character): 342 clocks
SzCmp, 64 bytes different string (first character): 11 clocks

lstrcmp, 64 bytes identical string: 1568 clocks
lstrcmp, 64 bytes different string (last character): 1619 clocks
lstrcmp, 64 bytes different string (first character): 2531 clocks

Press ENTER to exit...

[attachment deleted by admin]

[tenkey]

There is something fundamentally wrong with the premises here, if the strings are zero terminated, it does not mater if they are the same up near the end or not, the difference is measured with the zero terminator included.

Code Select Expand


"string",0
"string1",0


A single coparison algo will exit when the "1" is compared with the terminating zero as a mismatch.

Well, if indeed all the strings are 0-terminated, then the length to compare should include the terminator character. In other words, one more than the number of significant (or "interesting") characters.

[AeroASM]

Well, if indeed all the strings are 0-terminates, then you don't need a length.

[tenkey]

That's true, but the length is being used for optimizing speed.

[MichaelW]

Hi Mark,

Interesting! What were you running on? These are my results running on a P3:

Code Select Expand


SzCmp/lstrcmp speed comparison by Mark Jones (gzscuqn02ATsneakemailD0Tcom)
Timing routines by MichaelW from MASM32 forums: http://www.masmforum.com/
Please terminate any high-priority tasks and press ENTER to begin.

These are the three 64-byte strings being tested:
"Hello, this is an example of a MASM32 64-byte string comparison."
"Hello, this is an example of a MASM32 64-byte string comparison!"
"hello, this is an example of a MASM32 64-byte string comparison."

Timing results:

SzCmp, 64 bytes identical string: 402 clocks
SzCmp, 64 bytes different string (last character): 391 clocks
SzCmp, 64 bytes different string (first character): 18 clocks

lstrcmp, 64 bytes identical string: 372 clocks
lstrcmp, 64 bytes different string (last character): 967 clocks
lstrcmp, 64 bytes different string (first character): 3296 clocks


[Mark Jones]

Michael, my results were with an AMD XP 1800+. Those are some pretty big differences. :)

[roticv]

Your P3 seem to be faster than my Celeron 2.4ghz  :toothy

Timing results:

SzCmp, 64 bytes identical string: 903 clocks
SzCmp, 64 bytes different string (last character): 888 clocks
SzCmp, 64 bytes different string (first character): 49 clocks

lstrcmp, 64 bytes identical string: 2209 clocks
lstrcmp, 64 bytes different string (last character): 2297 clocks
lstrcmp, 64 bytes different string (first character): 3097 clocks


I think string opcodes are worse on newer computers.