javascript — Является ли \ 0 (& quot; \\ 0 «в строке регулярного выражения в стиле C) допустимой escape-последовательностью в регулярных выражениях C ++?

НОТА: Когда я сказал регулярное выражение [\0] Я имею в виду регулярное выражение [\0] (не содержится в строке в стиле C, которая будет "[\\0]"). Если я не заключил в это кавычки, это не строка в стиле C, и обратные слеши не должны интерпретироваться как экранирование строки в стиле C.

Вдохновленный этот вопрос и мое расследование, Я попробовал следующий код в Clang 3.4:

#include <regex>
#include <string>

int main()
{
std::string input = "foobar";
std::regex regex("[^\\0]*"); // Note, this is "\\0", not "\0"!

return std::regex_match(input, regex);
}

По-видимому, Clang не нравится это, поскольку он бросает:

std::__1::regex_error: Выражение содержало недопустимый экранированный символ или завершающий экранирующий символ.

Кажется, это [^\0] часть (изменяя его на [^\n] или что-то подобное работает нормально). Кажется, это недопустимый escape-символ. Я хочу уточнить, что я не говорю о '\0' символ (нулевой символ) или '\n' символ (символ новой строки). В строках в стиле C я говорю о "\\0" (строка, содержащая ноль обратной косой черты) а также "\\n" (строка, содержащая обратную косую черту n). "\\n" кажется превращается в "\n" с помощью двигателя регулярных выражений, но он задыхается "\\0",

Стандарт C ++ 11 говорит в разделе 28.13 [re.grammar], что:

Грамматика регулярного выражения, распознаваемая basic_regex объекты, созданные с использованием флага ECMAScript, определены в ECMA-262, за исключением случаев, указанных ниже.

Я не эксперт по ECMA-262, но Я попробовал регулярное выражение на JSFiddle и там хорошо работает на земле JavaScript.

Так что теперь мне интересно, если регулярное выражение [^\0] допустимо в ECMA-262, и стандарт C ++ 11 убрал его поддержку (в следующем материале ... except as specified below.).

Вопрос: Это \0 (не нуль-символ; в строковом литерале это будет "\\0") escape-последовательность, допустимая в регулярном выражении C ++ 11? Законно ли это в ECMA-262 (или виртуальные машины JS браузеров просто «слишком» снисходительны)? Какова причина / обоснование для различного поведения?

8

Решение

Это была ошибка в реализации libc ++ <regex>, Это должно быть исправлено теперь в транке, и это должно распространиться на код выпуска OS X в конечном счете.

Кроме того, вот выдержка из стандарта ECMA 262, которая является основой для этого сообщения об ошибке:

15.10.2.11 DecimalEscape

Производство DecimalEscape :: DecimalIntegerLiteral [lookahead ∉ DecimalDigit] оценивается следующим образом:

  1. Позвольте мне быть MV ДесятичногоIntegerLiteral.
  2. Если я равен нулю, вернуть EscapeValue, состоящий из <NUL> символ (значение Unicode 0000).
  3. Вернуть EscapeValue, состоящее из целого числа i.

Примечание: … \ 0 представляет <NUL> символ и не может сопровождаться десятичной цифрой.

2

Другие решения


По вопросам рекламы [email protected]