Wow someone's getting defensive.
I say I want A and B and you pick out B and ignore A.
To be fair, I didn't *ignore* anything. I ported your alias *command for command* to hash tables. It works exactly the same as your code, does exactly the same thing, and it's faster. So are you going to admit it's faster yet or are you going to cry about a bad experience at McDonalds?
Btw, the results here gave Hash: 220 @window: 480
And your point is? That I'm still right? Thanks. Sorry when I tested the code I stepped off the "all computers run at exactly the same speed" planet.
So much for keeping its order.
I'm not sure who "confirmed" this (I don't see anyone confirming it here).. Hash tables items are not ordered in memory
, yes, but if you practice what you preach and look at the code you'll see that my key names are in fact unique numerical indexes. Do you know what unique numerical indexes do when used as keys? They maintain order. $hget(yay,500) would get line 500, $hget(yay,200) would get line 200, etc.. I'm assuming you didn't actually understand this fact, or you wouldn't have made the above statement. To clarify, my hash table data *is* ordered, just not in your ram. Do you still think I'm wrong?
About all mIRC's search commands support regex. Glad you assumed I didn't know that. Glad you didn't bother to think one step further.
Huh? I didn't assume anything. I'm responding to your incorrect
statement based on what you said here
...if you want to search for a line that contains *!email@example.com in a certain token position, false positives are possible due to /filter's seeing it as a wildcard symbol
This is simply wrong
. First of all, they're not considered "false positives" if you incorrectly use a '*' as a literal when you know
mIRC will parse it as a wildcard. That's called: using a command incorrectly. If you want to search for a line that contains '*' you use a regular expression match and escape it so it's not treated in a special manner. What exactly was I assuming here? I'm merely telling you that you CAN use /filter to match literal '*'s. Are you still
saying you can't? Do you still think I'm wrong?
You don't seem to enjoy factual proof. I'm giving you working code with improved benchmark results that you yourself corroborate and for some reason my giving of this information makes you call me a "politician", which makes no sense to me. Rather than focusing on why my facts may be invalid you're more interested in horrible analogies and trying to insult me by calling me names. Real classy. I'm not sure how else I can convince you...