Regular expression Trap Description _ regular expression in browser

Before the beginning of this chapter, I would like to introduce an example to show that this incomplete abnormal optimization is reasonable or unreasonable.

The direct amount of string in C # is optimized very thoroughly ... We should be welcome to this optimization ...

String str= "Franky";

String str2= "Franky";

There is only one string object in memory and STR and STR2 have the same reference. Obviously it's very reasonable.

string n = "Franky", N2 = "Franky";
Response.Write (Object.referenceequals (N,N2)). ToString ());//true.

Some browsers have also done similar optimizations for regular expression direct quantities in some special cases.

alert (/\d/==/\d/);//All browsers are false this is reasonable because the regular expression is directly the same as the [] array direct Quantity {} object Direct quantity is a reference type

Let's see which browsers are optimized

function F2 () {
return/\d/;
}

Alert (F2 () = = F2 ());

The results here are different.

IE6 7 8 Opear10 Safari4 all returned False (the Safari3 in my virtual machine was not tested.) If anyone could help me with the results. I estimate that SAFARI3 will return true. Because the Maxthon3 engine seems to be safari3.

But

Firefox 2.0 3.0+ 3.5 3.6 Chrome 4 5 OPEAR9 Maxthon3 demo version with WebKit engine returns True

The interesting thing is that OPERA9 did the optimization and OPERA10 canceled the optimization. It seems that at least the opera team thinks this optimization is inappropriate ... (The disguise supports my point of view.)

See here you might wonder if it's a bug, not an optimization? Maybe it was a problem with the closure object or some bugs on the function object?

So let's look at the following example:

for (var i = 0; i < i++) Document.writeln (/\d/g.test (' + i));

The difference between the output of different browsers completely conforms to whether or not the above optimization classification.

That is, browsers that have not done optimizations return true, and those that are optimized are the result of alternating true false true false.

We're just a loop here. The loop in JS does not have an independent scope and does not produce a closure object. The root cause of this bizarre problem is that some browsers are smart-aleck optimizations.

Maybe people don't quite understand where the test results differ from ... The answer is that test is the same as exec if there is a/g behind the direct quantity. If the global global lookup parameter is set, the same test object records the index position of the last matching character. The next time it matches, it starts at this point. If there is no matching index <0 will still start with the 0 position character the next time this match occurs.

So it's OK to use exec in the above test.

So how do you avoid browser differences here? Easy way to remove/g

Here we must remember a promise to avoid the trap. Try not to use a regular direct amount within the function body or loop. If so, use the new RegExp (' \d ', g);

For exec, try to use String.match instead. Because match forces you to rely on whether there are/g to look for globally. does not create ambiguity.

var reg=/\d/can also be considered for test if it is in the loop; //here to/g remove. Please don't forget oh

for (var i = 0; i < i++) Document.writeln (reg.test (' + i));

In fact, this is the most reasonable way to use it. The reason is that we only produce a regular object here and use it over and over again. In essence, it is for optimization. But we avoided the different results of the browser's own tuning differences.

Finally, we found that the so-called trap occurred mainly/g improper use. Both exec and test are so if the use of/g is reasonable regardless of whether the browser has abnormal optimization. The results will be correct ... The only difference is that the optimized browser does not need to repeatedly generate a regular object and then garbage collection and then generate a regular object .... So repeated ...

Then we find that the problem is avoided by following the above principles ...