Оба выражения modern полностью решают задачу извлечения данных из пар ключ-значение, последовательно сохраняя ключ и парное ему значение в переменных $1 и $2 соответственно из данных приведенной Вами же в Вашем же примере адресной (для регулярного выражения) строки. Меня это поведение кода абсолютно не смущает. ЧЯДНТ?
В общем — есть желание — выкладывайте пример исходных данных из жизни, нет — заминаем для ясности, бо последние дцать ответов — малоинтересные сообществу попытки уточнить, что имел ввиду отвечающий, когда не так понял вопрошающего.
Давайте кусок настоящих (тождественных настоящим) данных — я запутался, о чем речь и почему нас интересует произвольный текст в кавычках внутри валидного xml, а пример — с парами ключ-значение? Что явлется данными, что разделителями?
PS. Если Вы контролируете оба конца, то самое лучшее — акисома «разделитель является собственностью программиста! попытка подделки разделителя преследуется по закону». Т.е. объявляете для себя разделителем «что-то», и это «что-то» вырезаете из входящего текста до его комплексной обработки.
Нет, не ответили :)
Я Вас русским по белому спрашиваю — слеш экранирует любой символ, включая слеш, или единственной экранируемой конструкцией является \" ?
Последовательность \\" для нас означает «экранированный слеш и кавычка» или «слеш и экранированная кавычка»? Теперь Вы понимает, почему это важное соглашение?
Сделайте копипаст кода по ссылке и запустите уже скрипт! Метод научного тыка — наше все :)
Вся магия в cmpthese из use Benchmark qw/cmpthese timethese/;
Таблицы хронометражей сам только вчера подсмотрел у DurRandir — сходите в его пример кода.
Хорошо, поехали с Вашим замечанием — «возможность экранирования» — активная, как в Perl — 2 слеша -> 1 «экранированный» слеш или экранирование экранируемых символов нас не интересует? Это нифигово важное соглашение — отнеситесь серьезно.
Согласитесь — оптимизация решения общих вопросов в общем виде должна начинаться с уточнения вопроса и вида, а не с ковыряния алгоритма. При всем Вашем желании Вы не сможете мне на доске нарисовать сетку координат, в которую влезет любой придуманый мной прямоугольник.
Эм. Как у меня часто случается — «Подумал не то, что сказал». Конечно же стоит использовать управление компиляцией шаблона, если он используется далее в цикле и т.п.
А имел ввиду я всякие «суб-оптимизационные» трюки с вариантом шаблона, который по тем или иным причинам, не связанным с логикой регулярных выражений, выполняется быстрее в строго определенной среде.
Может быть домен .TEL — идеальное решение для нужд автора?
Домен TEL — это первый домен верхнего уровня, для которого не нужен хостинг, вся информация хранится в DNS.
Регистрируя домен .TEL, вы сразу получаете сайт-визитку, где сможете указать всю контактную информацию, которую посчитаете необходимой. Обновления при этом происходят практически моментально. Предоставляемый сайт-визитка уже оптимизирован для просмотра с мобильных устройств и индексации поисковыми системами.
Первое правило по Фридлу (во всяком случае для меня) — понимайте свои данные.
Если Вам нужно найти пары ключ-значение, при этом значение является строкой, находящейся в кавычках, отделенной от следующего ключа пробелом, так и напишите:
$str =~ /\G([-a-zA-Z0-9_]+) = "([^\s]*)" /gcx; # modern_1 - пессимистичный вариант, когда значение может быть пустым
или $str =~ /\G([-a-zA-Z0-9_]+) = "([^\s]+)" /gcx; # medern_2 - оптимистичный вариант, у нас гарантировано не будет пустых значений
Можно я Вас отговорю от управления компиляцией?
Пожалуйста, никогда не делайте так, даже если Вы точно знаете цель данного действа.
Управление компилятором — грязный трюк, который гарантировано закончится полным фиаско при минимальном обновлении внутренней логики.
Вообще, я как раз и пытаюсь заинтересовать читателя самостоятельно узнать побольше о принципах работы НКА и возможностях, которые ему станут доступны, отсылая к лучшей книге по этой теме.
Я, знаете ли, Фридла не заменю при всем желании, потому как ориентируюсь в вопросе не столь хорошо.
Готов обсудить Ваше предложение подробнее, как только Вы явно озвучите, что именно Вы имеете ввиду под определением «Backtracking». Не хотелось бы дискутировать о преимуществе арбузов над помидорами.
В общем же виде сама модель НКА, применяемого практически во всех продуктах (за редким исключением), формализуется как «поиск самого длинного совпадения, ближнего к левому краю», т.е. механизм внутреннеоптимизирован.
И как пишет Фридл (стр.314)
Если Вам абсолютно ничего не известно о целевых данных, выбирайте максимальный квантификатор, поскольку он обычно оптимизируется чуть лучше минимального, особенно если следующий элемент регулярного выражения не позволяет использовать оптимизацию по символу, следующему за минимальным квантификатором.
и ранее (стр.304)
Проверка символа, следующего за минимальным квантификатором.
При использовании минимальных квантификаторов в конструкциях вида /"(.*?)"/ механизм должен постоянно переходить между проверками совпадения квантифицированной конструкции (точки) и тем, что следует после нее ("). По этой и по ряду других причин минимальные квантификаторы обычно работают гораздо медленнее максимальных.<...> Если минимальный квантификатор заключен в сохраняющие круглые скобки, управление приходится постоянно передавать внутрь скобок и за их пределы, что приводит к дополнительным затратам времени.
Я бы рекомендовал использовать (+) а не (*) в качестве квантификатора всегда, когда это возможно.
Что до negated character classes [^abc] — да, очень эффективная техника, но с большими ограничениями.
Потратил пол-минуты на хождение по ссылке. Повеселили, чесслово.
Вы, юноша, вместо того чтобы полную ерунду писать — лучше потратьте время на то, чтобы прочитать ответ умных людей, да осознать его.
Резюме ответа саппорта — модификатор '/e' позволяет выполнять код в шаблоне подстановки(замены), как это и указано в документации.
Приведенный Вами код выполняет ровно то, что Вы написали, а не то, что Вы подразумевали при его написании. Именно в этом корень Ваших «багов».
Что же до использования регулярных выражений и модификаторов — все они абсолютно безопасны и не содержат никаких «багов» и «дыр». Во всяком случае до тех пор, пока разработчик сам их туда не внедрит, мало ли какие у него идеи.
В бесконечной рекурсии тоже иногда бывает смысл, знаете ли.
Вот я не понимаю, зачем пытаться учить на плохих примерах?
Не надо так:
4. Шестнадцатиричный цвет
Паттерн: /^#?([a-f0-9]{6}|[a-f0-9]{3})$/
Надо вот так:
Паттерн: /^#?(?:[0-9a-f]{3}){1,2}$/
Если Вам нужно найти 3 или 3+3 последовательностей — так и скажите.
PS. Вот чего я никак не пойму — это почему в символьном классе последовательность задается «тире», а в полном квантификаторе — через запятую? Инопланетная логика.
Кстати, использование в квантификаторе логики «последовательность» или «список» позволила бы делать подобные вещи более красивыми. Жаль, что синтаксис уже точно не изменится.
Если помечтать, то было бы [a]{1-3} — от 1 до 3-х 'a' или [a]{1,3} — точно 1 или точно 3 'a'. Красота!
В общем — есть желание — выкладывайте пример исходных данных из жизни, нет — заминаем для ясности, бо последние дцать ответов — малоинтересные сообществу попытки уточнить, что имел ввиду отвечающий, когда не так понял вопрошающего.
PS. Если Вы контролируете оба конца, то самое лучшее — акисома «разделитель является собственностью программиста! попытка подделки разделителя преследуется по закону». Т.е. объявляете для себя разделителем «что-то», и это «что-то» вырезаете из входящего текста до его комплексной обработки.
Я Вас русским по белому спрашиваю — слеш экранирует любой символ, включая слеш, или единственной экранируемой конструкцией является
\"?Последовательность
\\"для нас означает «экранированный слеш и кавычка» или «слеш и экранированная кавычка»? Теперь Вы понимает, почему это важное соглашение?Сделайте копипаст кода по ссылке и запустите уже скрипт! Метод научного тыка — наше все :)
Вся магия в cmpthese из use Benchmark qw/cmpthese timethese/;
Хорошо, поехали с Вашим замечанием — «возможность экранирования» — активная, как в Perl — 2 слеша -> 1 «экранированный» слеш или экранирование экранируемых символов нас не интересует? Это нифигово важное соглашение — отнеситесь серьезно.
Согласитесь — оптимизация решения общих вопросов в общем виде должна начинаться с уточнения вопроса и вида, а не с ковыряния алгоритма. При всем Вашем желании Вы не сможете мне на доске нарисовать сетку координат, в которую влезет любой придуманый мной прямоугольник.
А имел ввиду я всякие «суб-оптимизационные» трюки с вариантом шаблона, который по тем или иным причинам, не связанным с логикой регулярных выражений, выполняется быстрее в строго определенной среде.
Сердито и без головной боли.
Рассказ профессионала для профессионалов, а я попробывал то-же самое на пальцах объяснить.
Если Вам нужно найти пары ключ-значение, при этом значение является строкой, находящейся в кавычках, отделенной от следующего ключа пробелом, так и напишите:
$str =~ /\G([-a-zA-Z0-9_]+) = "([^\s]*)" /gcx; # modern_1 - пессимистичный вариант, когда значение может быть пустымили
$str =~ /\G([-a-zA-Z0-9_]+) = "([^\s]+)" /gcx; # medern_2 - оптимистичный вариант, у нас гарантировано не будет пустых значенийи получите
Rate std lazy plus unroll lazy_2 modern_1 modern_2 std 24660/s -- -38% -65% -74% -83% -92% -93% lazy 39456/s 60% -- -43% -58% -73% -87% -88% plus 69591/s 182% 76% -- -26% -52% -76% -80% unroll 93699/s 280% 137% 35% -- -35% -68% -73% lazy_2 143913/s 484% 265% 107% 54% -- -51% -58% modern_1 295080/s 1097% 648% 324% 215% 105% -- -14% modern_2 341672/s 1286% 766% 391% 265% 137% 16% --Мысли-то у Вас в правильном направлении пошли с
\s*Пожалуйста, никогда не делайте так, даже если Вы точно знаете цель данного действа.
Управление компилятором — грязный трюк, который гарантировано закончится полным фиаско при минимальном обновлении внутренней логики.
Вообще, я как раз и пытаюсь заинтересовать читателя самостоятельно узнать побольше о принципах работы НКА и возможностях, которые ему станут доступны, отсылая к лучшей книге по этой теме.
Я, знаете ли, Фридла не заменю при всем желании, потому как ориентируюсь в вопросе не столь хорошо.
В общем же виде сама модель НКА, применяемого практически во всех продуктах (за редким исключением), формализуется как «поиск самого длинного совпадения, ближнего к левому краю», т.е. механизм внутреннеоптимизирован.
И как пишет Фридл (стр.314)
и ранее (стр.304)
Я бы рекомендовал использовать (+) а не (*) в качестве квантификатора всегда, когда это возможно.
Что до negated character classes [^abc] — да, очень эффективная техника, но с большими ограничениями.
Вы, юноша, вместо того чтобы полную ерунду писать — лучше потратьте время на то, чтобы прочитать ответ умных людей, да осознать его.
Резюме ответа саппорта — модификатор '/e' позволяет выполнять код в шаблоне подстановки(замены), как это и указано в документации.
Приведенный Вами код выполняет ровно то, что Вы написали, а не то, что Вы подразумевали при его написании. Именно в этом корень Ваших «багов».
Что же до использования регулярных выражений и модификаторов — все они абсолютно безопасны и не содержат никаких «багов» и «дыр». Во всяком случае до тех пор, пока разработчик сам их туда не внедрит, мало ли какие у него идеи.
В бесконечной рекурсии тоже иногда бывает смысл, знаете ли.
Не надо так:
Надо вот так:
Паттерн: /^#?(?:[0-9a-f]{3}){1,2}$/
Если Вам нужно найти 3 или 3+3 последовательностей — так и скажите.
PS. Вот чего я никак не пойму — это почему в символьном классе последовательность задается «тире», а в полном квантификаторе — через запятую? Инопланетная логика.
Кстати, использование в квантификаторе логики «последовательность» или «список» позволила бы делать подобные вещи более красивыми. Жаль, что синтаксис уже точно не изменится.
Если помечтать, то было бы [a]{1-3} — от 1 до 3-х 'a' или [a]{1,3} — точно 1 или точно 3 'a'. Красота!