AWESOME! A few big picture questions...

[GCuser99]

First of all - this is impressive!

And good timing given MS's deprecation of VBScript and the start of the phaseout period for associated functionality, RegExp being one of those potentially doomed components.

As a current sign that the "writing is on the wall" for VBScript's RegExp, I just discovered that Malwarebytes AV defaults to blocking any attempt to use VBScript's RegExp in VBA code. The "block" can be turned off via MWB's settings, but it serves as motivation to start looking for alternatives now.

My experience with your code thus far has shown promise. I successfully tested it in a somewhat large and complicated ActiveX DLL coded in twinBASIC. To facilitate the test, I created a drop-in replacement wrapper for VBScript's RegExp so I did not have to modify any code in the ActiveX DLL. Thus far it has worked perfectly, while MWB is none-the-wiser.

One thing about the ActiveX DLL is that it uses RegExp to search/parse small strings so that performance is not a factor. But I did do a little large-string testing and observed that your code runs significantly slower than the VBScript's version. I'm wondering what your experience has been in performance testing and about your thoughts are on the feasibility of eventually improving performance?

Another concern of mine is your statement in your GitHub repo README.md "Please do not expect great results for non-latin characters (but give it a try). Can you elaborate more on this? Under what circumstances do you expect problems and why?

Something else you might consider but not a huge deal... I understand that it is probably easier on your development process to break your codebase into multiple modules as you have it. But my strong preference is to use your all-in-one solution so not to add unnecessary clutter in my VBA/twinBASIC code. I suspect most users are like me and would prefer the aio solution (which is likely the reason you went through the trouble to automate its build). But if that is the case, then it might make the user-experience less onerous and easier to provide feedback if you made the aio solution the main codebase instead of an alternative one. Just something to consider.

Anyway, thanks for sharing this and hoping that this project will remain an active one!

Mike

[sihlfall]

Thank you for taking the time to provide detailed feedback. This is very much appreciated and motivates me to work further on the project.

As to your questions:

1. Performance: The regex engine was written with performance in mind (at least, no unnecessary pessimization), yet there is definitely room for improvement. The first and most obvious issue is string handling in Visual Basic. Currently, the input is being read character-by-character by using Mid. This leads to the creation of many one-character strings. This can be avoided by memcpying the string to an integer array, sacrificing the "VB-only" goal at this point. It gives, however, a 30% performance improvement in reading the string. Minor optimizations are, probably, possible with respect to splitting the large SELECT statements into smaller ones,. Maybe adopting optimization techniques from other regex engines would also be possible.
2. Performance, second remark: Can you provide a test case (or several test cases) showing the performance difference between VBScript and this regex engine? Are you running compiled code (dll) or interpreted code (VBA)?
3. Performance, third remark: If you need the same pattern repeatedly, you should initialize the regex once and re-use it. That is, execute

   Dim regex As StaticRegex.RegexTy
   
   StaticRegex.InitializeRegex regex, _
      "(?<month>\w{3})-(?<day>\d{1,2})-(?<year>\d{4})"
   

   only once and keep the variable regex around.

4. Unicode: Unicode character handling is complicated. Case-sensitive matching should work as expected, but the engine does not (and probably will never) consider combinations like ¨ + o and ö as being equivalent. For case-insensitive matching, probably the identification of upper-case with their corresponding lower-case characters is limited (you need huge translation tables performing the uppercase-to-lowercase translation, and they will probably never be complete). I expect characters to be incorrectly identified as being different when it comes to latin characters with diacritics and non-latin characters (Greek, Russian, Japanese etc.). Honestly, I do not expect VBScript to be great on this, either. My goal is to see all the RE2 test cases pass.
5. AIO: Yes, I also think a single file would be easier to maintain.

Best regards,
sihlfall

[GCuser99]

Here are some quick and dirty twinBASIC numbers for searching a 1000 character string and enumerating 160 matches, in milliseconds:

Method	IDE	Compiled
VBS	.25	.23
StaticRegex	1.05	.36

That's very good actually - for this particular test StaticRegex took only about 50% longer in a compiled exe. I can live with that.

The main reason for me to prefer the "VB-only" goal is for Mac/Windows compatibility. But of course, you can maintain cross-platform compatibility using the more performative API - I think a good example is @cristianbuse's FastDictionary. So maybe performance optimization can be something to consider down the road a bit, but for now I think it's good enough.