Match Pattern Special Characters Confusion

[bienieck]

The page Special Characters for Match Pattern, documenting the special characters for the Match Pattern function, states that square brackets [] are special characters used to define a character class. It also mentions that:

"The Match Pattern function interprets special characters inside square brackets literally, with the following exceptions: -, ~, and ^."

At the same time, the special character \ is described as:

"Cancels the interpretation of any special character in this list."

Now, my question is: Which takes precedence - cancelling with \ or defining a character class? My understanding is that if we have, for example, [~.\], this creates a character class that matches any character, including non-displayable characters, except . and \. In other words, [~.\] and [~\.] should produce the same result. However, the actual result differs.

It seems that canceling with \ has the highest priority, and \ inside [] is also treated as a special character. This would mean the list of exceptions (-, ~, and ^) is incomplete and should include \ as well.

Additionally, I believe the pattern used in Get File Extension.vi should not be \.[~\.]*$ but rather \.[~.]*$. It looks like the intention of the author was to escape .. However, the documentation explicitly states:

"Within square brackets, . is literal."

[wiebe@CARYA]

I think you're making it too difficult.

---

@bienieck wrote:

Now, my question is: Which takes precedence - cancelling with \ or defining a character class? My understanding is that if we have, for example, [~.\], this creates a character class that matches any character, including non-displayable characters, except . and \. In other words, [~.\] and [~\.] should produce the same result. However, the actual result differs.

Both the . and the \ are special characters.

[.\], that escapes the ']', so the reg ex isn't valid (the start '[' has no close ']'). For instance '[a\]]' tries to match 'a' and ']'.

[\.], this escapes the '.', so the reg. ex matches a '.', not 'any character'..

[.], , the '.' is a special character, but inside '[]' it doesn't need to be escaped. [.a] tries to match '.' and 'a'.

[~a], the '~' is a special character, but inside '[]' it doesn't need to be escaped. [~a] tries to match '~' and 'a'.

[bienieck · Accepted solution]

If so, I'm right about unnecessary escaping in the mentioned VI and the incomplete documentation.

[bienieck]

---

wiebe@CARYA wrote:

[~a] tries to match '~' and 'a'.

---

I think you are not correct here.

[wiebe@CARYA]

---

@bienieck wrote:

---

wiebe@CARYA wrote:

[~a] tries to match '~' and 'a'.

---

I think you are not correct here.

---

I looked at Match Regular Expression. Match Pattern could indeed be different.

I hardly use Match Pattern anymore, as Match Regular Expression is more powerful, and much better documented (as PCRE isn't limited to NI).

[bienieck]

I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.

[wiebe@CARYA]

---

@bienieck wrote:

I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.

---

For the CPU: probably.

For the programmer: not always.

A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...

[Martin_Henz]

---

A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...

---

I'm with you - in most cases. Speed also depends on much less features of Match Pattern. Think of backward references, named substrings, greedy/ungreedy, atomic grouping, possessive quantifiers and much more.

I don't like Match Regular Expression because I cannot specify the substring I need. The underlaying call library node is known, so it is possible to implement that. But there is actually no way for named substrings.

[Yamaeda]

---

wiebe@CARYA wrote:

---

@bienieck wrote:

I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.

---

For the CPU: probably.

For the programmer: not always.

A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...

---

If i remember Darrens video correctly one of the arguments against Match Regular Expression was that it was an Xnode and could cause issues when compiling, apart from being noticably slower on simple tasks. Often the last part is irrelevant, but it can be good to know.

[wiebe@CARYA]

---

@Yamaeda wrote:

---

wiebe@CARYA wrote:

---

@bienieck wrote:

I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.

---

For the CPU: probably.

For the programmer: not always.

A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...

---

If i remember Darrens video correctly one of the arguments against Match Regular Expression was that it was an Xnode and could cause issues when compiling, apart from being noticably slower on simple tasks. Often the last part is irrelevant, but it can be good to know.

---

It doesn't need to be an XNode.

Sometimes the XNode isn't convenient at all: Add Match Regular Expression sub VI - NI Community