НОТА: Когда я сказал регулярное выражение [\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 браузеров просто «слишком» снисходительны)? Какова причина / обоснование для различного поведения?
Это была ошибка в реализации libc ++ <regex>
, Это должно быть исправлено теперь в транке, и это должно распространиться на код выпуска OS X в конечном счете.
Кроме того, вот выдержка из стандарта ECMA 262, которая является основой для этого сообщения об ошибке:
15.10.2.11 DecimalEscape
Производство
DecimalEscape :: DecimalIntegerLiteral [lookahead ∉ DecimalDigit]
оценивается следующим образом:
- Позвольте мне быть MV ДесятичногоIntegerLiteral.
- Если я равен нулю, вернуть EscapeValue, состоящий из <NUL> символ (значение Unicode 0000).
- Вернуть EscapeValue, состоящее из целого числа i.
Примечание: … \ 0 представляет <NUL> символ и не может сопровождаться десятичной цифрой.