Before the beginning of this chapter, I will introduce an example to illustrate whether this incomplete and perverted optimization is reasonable or unreasonable...
The optimization of direct string quantity in c# is very thorough... We should welcome this kind of optimization...
string str="franky";
string str2="franky";
There is only one string object in memory and str and str2 have the same reference. Obviously this is very reasonable.
string n = "franky", n2 = "franky";
(((n,n2)).ToString());//True.
So in some special cases, some browsers have also made similar optimizations for the direct quantity of regular expressions.
alert(/\d/==/\d/);//All browsers are false, which is reasonable because the direct quantity of regular expressions is the same as the direct quantity of [] array {} object {} is the reference type
Let's see which browsers have optimized
function f2() {
return /\d/;
}
alert(f2() == f2());
//The results here are different
ie6 7 8 listen10 safari4 returns false (Safari3 in my virtual machine is broken and it was not tested. If anyone has any, please help me test the result. Thank you. I guess safari3 will return true. The reason is that the engine used by maxthon3 seems to be from safari3)
but
firefox 2.0 3.0+ 3.5 3.6 chrome 4 5 listen9 maxthon3 demo version Use the webkit engine to return true
The interesting thing is that opera9 has been optimized and opera10 has cancelled this optimization. It seems that at least the operator team believes that this optimization is inappropriate... (It supports my point of view in disguise.)
When you see this, you may wonder if it is a bug instead of the so-called optimization? Maybe something is wrong with the closure object or is it caused by some bug on the function object?
Then let's take a look at the following example:
for (var i = 0; i < 10; i++) (/\d/('' + i));
The differences in output results of different browsers are fully in line with the above classification of whether to optimize.
That is, browsers that have not been optimized will return true, while browsers that have been optimized will be the result of true false true false alternating.
We are just a loop here. The loop in ..js has no independent scope and will not produce closure objects. So it is certain that the root cause of this weird problem is that some browsers are clever in their own optimization.
Maybe you don't understand where the difference comes from the test result... The answer is that test is the same as exec. If /g is followed by the direct quantity. The global global search parameters are set, then the same test object will record the index position of the last matching character. The next time you match again, it will start from this position. If not, the matching index <0 will still start from the 0 position character next time you match here.
So the above test is also OK to use exec.
So how to avoid browser differences here? Simple way to remove /g
Here we need to remember a convention to avoid traps. Please try not to use a regular direct quantity in the function body or loop. If this is the case, please use new RegExp('\d',g);
Try to use exec instead. Because match forces you to rely on whether there is /g for global search... there will be no ambiguity.
For test, if it is in a loop, you can also consider var reg=/\d/;//If you want it here/g remove it... Please don't forget
for (var i = 0; i < 10; i++) (('' + i));
In fact, this is the most reasonable way to use it. The reason is that here we only generate a regular object and use it repeatedly... In essence, it is also for optimization. But we avoid the different results caused by the browser's own optimization differences.
Finally, we found that the so-called trap mainly occurs because of the improper use of /g. Whether it is exec or test, if it is reasonable to use /g, regardless of whether the browser has abnormal optimization, the execution result will be correct... The only difference is that the browser that has optimized does not need to repeatedly generate a regular object and then garbage collection, and then generate a regular object... It's just so repeated...
Then we found that if we abide by the above principles, this problem has also been avoided...