Patch to the new _INSTRREV command

[SMcNeill]

Since Fellippe is so adamant that _INSTRREV remain broken the way it is, I took the time to write up a simple little patch script for folks to use with the new release.

Code: QB64: [Select]

1. $CONSOLE:ONLY
2. 'we use console so we can see the output of any shell which is going on.
3. _TITLE "_INSTR Fix Runtime"
4. _DEST _CONSOLE
5.  
6. CHDIR "internal\c\"
7.  
8. OPEN "libqb.cpp" FOR INPUT AS #1
9. OPEN "libqb.tmp" FOR OUTPUT AS #2
10. DO
11.     LINE INPUT #1, temp$
12.     IF INSTR(temp$, "int32 func__instrrev(int32 start,qbs *str,qbs *substr,int32 passed)") THEN SetFlag = -1
13.     IF SetFlag THEN 'we're down at the proper function to change
14.         IF INSTR(temp$, "if (start<1){") THEN 'we found the line to change.
15.             PRINT #2, "    if (start<0){"
16.             PRINT "Fix applied."
17.             SetFlag = 0
18.             SetFlag2 = -1
19.         ELSE
20.             PRINT #2, temp$
21.         END IF
22.         IF INSTR(temp$, "void sub_mid") THEN SetFlag = 0 'make certain we don't change anything else, in case the file was previously altered.
23.     ELSE
24.         PRINT #2, temp$
25.     END IF
26. LOOP UNTIL EOF(1)
27. CLOSE
28.  
29. IF SetFlag2 THEN
30.  
31.     KILL "libqb.cpp"
32.     NAME "libqb.tmp" AS "libqb.cpp"
33.  
34.     SHELL "purge_libqb_only.bat"
35. ELSE
36.     KILL "libqb.tmp" 'delete the duplicate we made of the file, as it's basically an exact copy of libqb.cpp.
37.     PRINT "Changes not made.  You may have already ran the patch, or else the QB64 source has been fixed itself."
38. END IF

This changes nothing much with _INSTRREV, except 0 no longer counts as a substitute shortcut for LEN(mainstring$).  With the patch, simple code like the following works as one would expect it to in QB64:

Code: QB64: [Select]

1. seed = LEN("1111") + 1 'add one to the length to make certain we start at the end of the string we want to search
2. DO
3.     seed = _INSTRREV(seed - 1, "1111", "1")
4.     PRINT seed
5.     SLEEP
6. LOOP UNTIL seed = 0

This now prints the expected output of 4, 3, 2, 1, 0, and then terminates without going into an endless loop.

Without  the patch, we get an output of 4, 3, 2, 1, 4, 3, 2, 1, 4, 3, 2, 1, 4, 3, 2, 1, .... to infinity and beyond!  It's an endless loop.

If you like the command as Fell has it currently, simply leave it as it is.  If you want it to behave more like the rest of our QB64 commands and use 0 as a termination sequence, then copy and run the patch from the QB64 v1.3 version you downloaded.

It's that simple of a fix!  Enjoy! 

[RhoSigma]

And then ??

Everybody who has fixed his personal copy of QB64 is incompatible with the entire rest of the QB64 user base. Imagine you post a code snip which does invoke _INSTRREV in the way you want it (or what you believe is the right way), then this code will pobably give unexpected results to all users, who paste & run it in their own and most probably unpatched QB64 version.

BTW - I fully agree with Fellippes stance on this function, but don't be in the mood for a war of words here. Following your discussions about this topic throughout the day just reminds to Clippy. Are you?

[_vince]

In the QB days you'd have to write your own instrrev sub or share it with others. I'm in disagreement with any new statement/function that isn't a direct extrapolation of old functionality to modern hardware (i.e. higher resolution, more colors, less memory constraints). This would include things like _R2D, _instrrev, _trim$, _pi, etc.  These kinds of functions also make it harder to port across *BASIC variants given that they typically share a standard few

[SMcNeill]

And then ??

And then....

You have a copy of QB64 where the command behaves as you expect it to.

Everybody who has fixed his personal copy of QB64 is incompatible with the entire rest of the QB64 user base. Imagine you post a code snip which does invoke _INSTRREV in the way you want it (or what you believe is the right way), then this code will pobably give unexpected results to all users, who paste & run it in their own and most probably unpatched QB64 version.

So??

They’d just post a response of, “Doesn’t work for me.”   Then you either tell them, “Patch QB64, or modify it to work on your system.” 

It’s something we see all the time with code being shared.  What works for one produces unexpected results for another — like for my Wallpaper Changer not working as expected for wide screen displays. 

BTW - I fully agree with Fellippes stance on this function, but don't be in the mood for a war of words here. Following your discussions about this topic throughout the day just reminds to Clippy. Are you?

So, Fell’s reason for not wanting to fix it is, “It wasn’t found 10 months ago,” and, “Steve’s not a team player.”  Your reason is, “Steve must be Clippy.”

Both of you are good at basically calling folks names, but that’s not going to do *anything* to convince me, or anybody else, that it performs better without the patch.  Show us even one example where the current method performs better.

Currently you have to check for 2 things:
1) Is the result 0?  If so, no more matches can be found.
2) Is the result 1?  If so, we’re at the end of the search string; manually stop searching.

All the change does is eliminate the need for the second, unnecessary check.  If you’re at the end of the string, logically, you can’t have any more matches.  We should terminate at 0, not start back over at the far right of the search string and repeat the process again.

If INSTR behaved as _INSTRREV currently does, you’d have to check to make certain you stopped searching the string at the last byte in it, or else you’d start over fresh from the beginning.  Would that somehow be a better way for INSTR to perform?

If not, then why do you think _INSTRREV should perform in such a manner?

[Petr]

Hi Steve. You re right. Seriously. This should be repaired. For Fellippe: How much times you use negative number for this function? Just by chance. We can be glad, that Pete discovered it.

[FellippeHeitor]

@Petr check the example code in the wiki. It starts search as -1 as intended (and as explained in the wiki article too). http://www.qb64.org/wiki/INSTRREV

[SMcNeill]

@Petr check the example code in the wiki. It starts search as -1 as intended (and as explained in the wiki article too). http://www.qb64.org/wiki/INSTRREV

Starting with -1 is as intended, but when would you ever start the function with 0?  0 should be the termination value, just as it represents FALSE in QB64, with any other value being TRUE.

[Petr]

@Petr check the example code in the wiki. It starts search as -1 as intended (and as explained in the wiki article too). http://www.qb64.org/wiki/INSTRREV

Nice examples. They won't reveal this error. But we have a great team where one team player found a bug and another wrote a program to fix it. :-D

 

[FellippeHeitor]

we have a great team

Exactly.

@Steve: whatever, buddy. Do as the world wants. I'm so wrong in everything. Love, Fellippe.

[SMcNeill]

Nice examples. They won't reveal this error. But we have a great team where one team player found a bug and another wrote a program to fix it. :-D

If our goal is to have the command perform as it does in other languages, then either the wiki is wrong, or our implementation is completely off.

One inconsistency between our wiki (http://www.qb64.org/wiki/INSTRREV) and .NET’s documentation (https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualbasic.strings.instrrev?redirectedfrom=MSDN&view=netframework-4.7.2#Microsoft_VisualBasic_Strings_InStrRev_System_String_System_String_System_Int32_Microsoft_VisualBasic_CompareMethod_ ) is here:

Us: ... returns LEN(baseString$) with an empty subString$.
.NET: .... if StringMatch is zero-length   then return Start.

So for us, _INSTRREV(6, “abcdefghijklmnop”, “”) would return 16 — the length of the base string.
In .NET, it would return 6, as 6 is the start value.

Bug in _INSTRREV, or just documentation in the wiki?  Or is this simply how we want to implement it?  I don’t have a clue if it’s “as intended”, or not.  It’s just something I noticed when comparing documentations between the languages.


The other big difference is that .NET tosses an exception (ERROR), if the seed is 0, or < -1.

I don’t see where it’d really matter much if we use any negative number the same as -1, but I’d definitely rather see 0 be a termination value for us, instead of just tossing an error. 

[Petr]

Edit: This was such a stupid claim that I deleted it.

[Dimster]

I'm very much a neanderthal when it comes to programming so very sheepish in expressing an opinion here but...both Fellippe and Steve have made some excellent points and for my purposes (ie a hobbist programmer writing for my personal enjoyment and not commercially) I'm wondering if we could have both versions. Does it have to be one or the other? Could there be a _INSTRREVf and a _INSTRREVs ? Would one or the other work better with that String Math? I am finding that many of the older programs I wrote in Qbasic worked with printing values to multiple screens as in PRINT A. Since finding QB64 a year ago, I have relied more and more on _Printstring , consequently a huge dose of Str$(a) now populates my coding. QB64 has been offering a lot more in String manipulation than Qbasic so I'm wondering if both versions might strength this aspect of QB64.

[TempodiBasic]

Hi guys
I  love your energy!

this issue let me remember Protagora https://en.wikipedia.org/wiki/Protagoras 

πάντων χρημάτων μέτρον ἐστὶν ἅνϑρωπος, τῶν μὲν ὄντων ὡς ἔστιν, τῶν δὲ οὐκ ὄντων ὡς οὐκ ἔστιν

Homo est mensura omnium rerum: entium ut sint, non entium ut non sint

.
In the issue this let me think to how many different perspectives are avaiable for this function. It (the function) can appear useful or unuseful, right or wrong, normal or strange, in BASIC style or out of BASIC style as soon as we change the point of view.
In this thread only the two versions (Fellippe and Steve) are discussed, but in how many other ways can this function be build or modded?
 Only your creativity and energy can answer to this question!


About

Does it have to be one or the other? Could there be a _INSTRREVf and a _INSTRREVs ?

I can imagine that the forth parameter Mode%, that is absent in QB64 version, can be converted to activate the wanted behaviour of the function by the user.
It can be possible that in some situations the coder find useful the loop mode (FELLIPPE) while another coder or the same coder in another situation find useful the one ride mode (STEVE), so the coder can choose how _INSTRREV can work by Mode$ parameter!
To win 50 to 50 this is my pseudocode (type in BASIC, please don't ask to write in CPP, my CPP is so dusted!)

-------

DIM modeValue as integer
if mode$ = "FELLIPPE" then

 modeValue = -1

elseif mode$="STEVE" then

modeValue = 0

else

_INSTRREV =0

exit function

end if

------------

TADA! What do you think about ?

[codeguy]

Code: QB64: [Select]

1. a$ = "pat pat tom pat robert harry james felix sam pat roger dennis sandrab donald ralph pat felicia cathy harriet albert david sam katie frank pam sarah judy pat"
2. b$ = "pat"
3. x& = 0
4. p& = LEN(a$) - LEN(b$) + 1 - x&
5. DO
6.     IF MID$(a$, p& - x&, LEN(b$)) = b$ THEN
7.         PRINT p& - x&; LEN(a$); MID$(a$, p& - x&, LEN(b$))
8.         x& = x& + LEN(b$)
9.     ELSE
10.         x& = x& + 1
11.     END IF
12. LOOP WHILE x& < p&
13.  

provided lengths of b$ <= length of a$, if x& = p&, the b$ is NOT contained in a$.
an idea for you, so you can start at 0. p&-x& would be the returned value for a function. a return of 0 means it's simply not there. no messy string reversal. just good old subtraction and addition.

[Pete]

I responded over in my thread, here: https://www.qb64.org/forum/index.php?topic=1243.msg104642#msg104642