Наша таблица Внешняя таблица
---------------------------------- ------------------------
1101 | улица | Большая Морская улица Большая Морская
1102 | проспект | Заячий Заячий проспект
1103 | линия | 22-я В. О. 22-я линия В. О.
Регулярные выражения vs тупой поиск
Предлагаю пообщаться на означенную тему.
Сам я не пользовался регулярками, но хочу послушать более продвинутых товарищей.
Срач можно считать открытым.
Сам я не пользовался регулярками, но хочу послушать более продвинутых товарищей.
Срач можно считать открытым.
пользовала и тупой поиск и регулярки, последнее одназначно рулезная вещь: быстро, по крайней мере с точки написания, коротко, качественно.
видала километры кода с тупым поиском, которые при помощи регулярок менялись на считанные строчки красивого, понятного кода. конечно, искать самому тоже надо уметь, не все алгоритмисты высого уровня .... это я о километрах кода, там писал не спец.
видала километры кода с тупым поиском, которые при помощи регулярок менялись на считанные строчки красивого, понятного кода. конечно, искать самому тоже надо уметь, не все алгоритмисты высого уровня .... это я о километрах кода, там писал не спец.
Разные задачи - разные инструменты. Прежде чем устраивать срач, нужно было все же попользоваться регулярками. Уже более 10 лет использую и то и то.
Цитата: mike
Разные задачи - разные инструменты. Прежде чем устраивать срач, нужно было все же попользоваться регулярками. Уже более 10 лет использую и то и то.
Тут такое дело... не в сраче. Просто охота услышать в каких случаях что лучше использовать...
Что такое "тупой поиск"? В приложении к чему вообще?
Цитата: oxotnik333
Тут такое дело... не в сраче. Просто охота услышать в каких случаях что лучше использовать...
ну, я конечно особого опыта не имею, но что есть:
если мне в тексте приличного размера и с наворотами по содержанию, конкретней html страница например, надо было вытянуть спец. информацию, которую там надо было еще найти опираясь на определенные текстовые признаки - руками я перебирать точно это не хотела, т.е. использовать перебор, какие то функции для работы с текстом и т.д.. регулярки было отличным выходом, для меня. видела работающий код без регулярок, жуть еще та, читать мягко говоря такое трудно.
а если дана обыкновенная строка, скажем сотня символов, а то еще меньше, то думаю для ее обработки регулярки скорее всего не нужны, это типа на муху с охотничьим ружьем идти, но и тут есть исключения: при помощи регулярок шаблоны задаются: емайл, номеров телефона и т.д., думаю это удобней, чем самим проверять вручную, несмотря на то, что речь о строке весьма небольших размеров. поэтому mike правильно сказал, от задачи зависит, и к этому трудно что то прибавить )
Если верить Фридлу, то регулярки нужно использовать везде, где только можно.
Я думаю, тут многое зависит от доступности регулярок. Если в Перле или дотнете они есть сразу же под рукой, то их и используют. А в C/C++ из коробки регулярок нет, поэтому они не так популярны в этой среде.
Olga пишет, код с регулярками становится намного короче и понятней, чем без них. Насчёт "короче", да, соглашусь. А вот "понятней" - тут можно поспорить. Сложную чужую регулярку понять весьма трудно.
P.S. Хотелось бы услышать мнение hardcase'а насчёт Nemerle.Peg - способен ли он заменить регулярки во всех случаях, и насколько удобно.
Я думаю, тут многое зависит от доступности регулярок. Если в Перле или дотнете они есть сразу же под рукой, то их и используют. А в C/C++ из коробки регулярок нет, поэтому они не так популярны в этой среде.
Olga пишет, код с регулярками становится намного короче и понятней, чем без них. Насчёт "короче", да, соглашусь. А вот "понятней" - тут можно поспорить. Сложную чужую регулярку понять весьма трудно.
P.S. Хотелось бы услышать мнение hardcase'а насчёт Nemerle.Peg - способен ли он заменить регулярки во всех случаях, и насколько удобно.
Цитата: koodeer
Olga пишет, код с регулярками становится намного короче и понятней, чем без них. Насчёт "короче", да, соглашусь. А вот "понятней" - тут можно поспорить. Сложную чужую регулярку понять весьма трудно.
конечно, если нет навыка использования регулярных выражений, то очень сложно, и не только чужую, свою через некоторое время тоже не поймешь. но мне легче вспомнить, освежить правила написания регулярок и затем разобраться с рег. выражением, чем читать километры кода. ну есть у меня пример из жизни, очень уж наглядный он был для меня.
По работе и не по работе часто приходится сталкиваться с задачами, требующими разбора текста. Мне очень часто советуют регулярки, но лично я их применение вижу сильно ограниченным. То ли мне задачи такие попадаются, то ли регулярки банально не для моего ума...
Чтобы не быть голословным, -- задача:
Используемая СУБД (Oracle) поддерживает регулярные выражения POSIX искаропки. Можно ли решить данную задачу при помощи регулярок?
Я посчитал, что регулярки тут неуместны, и решил задачу функционально.
Чтобы не быть голословным, -- задача:
Цитата:
Найти соответствия улиц в двух разных таблицах (одна из них берётся из внешнего источника), сравнивая их по именам.
На нашей стороне тип уличного объекта (улица, проспект, линия и т. п.) хранится в отдельном поле, а во внешней таблице -- внутри названия, с учётом грамматики русского языка.
На нашей стороне тип уличного объекта (улица, проспект, линия и т. п.) хранится в отдельном поле, а во внешней таблице -- внутри названия, с учётом грамматики русского языка.
Код:
Предварительные исследования показали, что сопоставление выполняется быстрее, если сравнение значений делается ядром СУБД, а не внутри функции. Соответственно, задача следующая:
Цитата:
Реализовать функцию, приводяющую названия улиц к некоторому общему виду:
Код:
function ordered_tokens(source varchar2) return varchar2;
Подразумевается использование функции в запросе следующим образом:
Код:
SELECT
our_table.steet_code, our_table.steet_name, external_table.code
FROM
our_table,
external_table
WHERE
ordered_tokens(our_table.street_name) = ordered_tokens(external_table.street_name);
our_table.steet_code, our_table.steet_name, external_table.code
FROM
our_table,
external_table
WHERE
ordered_tokens(our_table.street_name) = ordered_tokens(external_table.street_name);
Используемая СУБД (Oracle) поддерживает регулярные выражения POSIX искаропки. Можно ли решить данную задачу при помощи регулярок?
Я посчитал, что регулярки тут неуместны, и решил задачу функционально.
И да прибудет с нами срач великий и могучий по поводу и без. ]:->
Цитата: koodeer
P.S. Хотелось бы услышать мнение hardcase'а насчёт Nemerle.Peg - способен ли он заменить регулярки во всех случаях, и насколько удобно.
Смотрел и то, и другое. Впечатлился. Именно под впечатлением лишний раз пиарю Nemerle :).
VladD2 хорошо расписал, почему регулярки популярны: они в шаговой доступности, потому и используются повсеместно. В тех языках, где их нет из коробки, они используются существенно меньше, даже если можно легко скачать дополнительную либу (типа boost.regex). И я согласен, что будь PEG встроен везде, то регулярки могли бы резко сдать свои позиции.
VladD2 хорошо расписал, почему регулярки популярны: они в шаговой доступности, потому и используются повсеместно. В тех языках, где их нет из коробки, они используются существенно меньше, даже если можно легко скачать дополнительную либу (типа boost.regex). И я согласен, что будь PEG встроен везде, то регулярки могли бы резко сдать свои позиции.
На счёт читаемости регулярок хочу добавить. В Python, например, есть режим, позволяющий писать комментарии к частям регулярки. Что-то типа:
Подозреваю, что и в других языках такое есть. Похоже на "костыли", да и комментарии могут быть левыми. Но хоть что-то.
Сам не являюсь специалистом по регуляркам - использовал пару раз.
Код:
re.compile(r"""\s*([a-z])\s*= # var
\s*([a-z]+)\s* # object
(?:\(\s*(\d+)\s*\))?\s* # digit""", re.X)
\s*([a-z]+)\s* # object
(?:\(\s*(\d+)\s*\))?\s* # digit""", re.X)
Подозреваю, что и в других языках такое есть. Похоже на "костыли", да и комментарии могут быть левыми. Но хоть что-то.
Сам не являюсь специалистом по регуляркам - использовал пару раз.
Цитата: Kogrom
Подозреваю, что и в других языках такое есть.
Да, это "eXtended mode" в терминах PCRE. Кстати, вполне нормальный способ повысить читаемость палочек и скобочек:
Код:
'
~
(?:
\n+ \s*?
(?:
([-\~=+]){3,} # horizontal rules
| (={2,}) (.+?) (?: =*) # heading
)
\s*? $
)
| \[- (.{3,}?) -\] # special insets
| (\.{2,}) # ellipsis
~x'
~
(?:
\n+ \s*?
(?:
([-\~=+]){3,} # horizontal rules
| (={2,}) (.+?) (?: =*) # heading
)
\s*? $
)
| \[- (.{3,}?) -\] # special insets
| (\.{2,}) # ellipsis
~x'
Естественно, что от самой природы регулярок (всмысле скобочек) это не избавит, но по крайней мере это уже не тот лес, как было бы без них:
Код:
'~(?:\n+\s*?(?:([-\~=+]){3,}|(={2,})(.+?)(?:=*))\s*?$)|\[-(.{3,}?)-\]|(\.{2,})~x'
Регулярками сам часто ползуюсь (в PHP), они могут пару вещей сделать более быстро и просто, чем обычные строковые функции - просто не надо их использовать везде подряд (например, проверить строку на содержание только букв можно как trim($str, 'a..zA..Z') вместо preg_match('/[a-z]/i', $str).
Например, вот так можно распарсить строку вида "ключ=значение\nключ=...":
Код:
if (preg_match_all('/^ *(\w+) *= *(.+) *$/m', $str, $match))
$list = array_combine($match[1], $match[2]);
$list = array_combine($match[1], $match[2]);
При этом одновременно очищаем ключи/значения от пробелов в начале и конце и заодно допускаем только буквы и цифры (\w) в ключах.
Я все же так и не понял, что такое "тупой поиск"? Это когда ты берешь HTML страницу, например, запихиваешь ее в здоровенную строку, и потом идешь по ней в цикле, пока не найдешь первую подстроку <image, например, потом что-то делаешь, запоминаешь, и идешь дальше? Ну так это маразм в случае сколько нибудь сложного поиска. Как тут было правильно замечено, во многих развитых и удобных языках регулярки поддерживаются на уровне синтаксиса языка даже, а не на уровне стандартной библиотеки.
Польза от регулярок очевидна. По сути, когда вы разбираете строку сами, вы используете собственный, крошечный парсер выражений, со своей неполной грамматикой и прочим... По сути, регулярки, если используются в сложных случаях, дают такие фичи, которые самому руками быстро написать крайне сложно.
Мне скорее интереснее похоливать на другие способы поиска. В том же документе, что HTML, что XML, можно искать регулярными выражениями. Можно построить дом дерево, и работать с нормальной, иерархической структурой данной - работать с ней руками, как с деревом. А можно искать XPath выражениями, что я например часто делаю. Например, задача "выбрать из XML документа все элементы, у которых есть аттрибут attr1" на XPath - одна короткая строка, и руками делать обход дерева..Не очень как-то.
Польза от регулярок очевидна. По сути, когда вы разбираете строку сами, вы используете собственный, крошечный парсер выражений, со своей неполной грамматикой и прочим... По сути, регулярки, если используются в сложных случаях, дают такие фичи, которые самому руками быстро написать крайне сложно.
Мне скорее интереснее похоливать на другие способы поиска. В том же документе, что HTML, что XML, можно искать регулярными выражениями. Можно построить дом дерево, и работать с нормальной, иерархической структурой данной - работать с ней руками, как с деревом. А можно искать XPath выражениями, что я например часто делаю. Например, задача "выбрать из XML документа все элементы, у которых есть аттрибут attr1" на XPath - одна короткая строка, и руками делать обход дерева..Не очень как-то.
Цитата: Zorkus
Я все же так и не понял, что такое "тупой поиск"?
Я думаю под "тупым поиском" не подразумевался цикл вида "for (i = 0; i < length; i++) if str == char ..." - речь скорее шла о функциях поиска подстроки (именно встроенных функциях) vs. регулярки. Вот ту действительно есть над чем подумать - регулярки почти всегда тяжелее обычной strpos хотя бы потому, что им нужна компиляция (особенно если регулярка вызывается в цикле и это язык вроде PHP, а не JS, который перекомпилирует регулярку каждый раз - то это весьма медленно).
Заезженный пример проверки на число (preg_match("^\d+$") vs. is_numeric) более-менее очевиден, но, например, без использования регулярок можно также определить, содержит ли строка символы из нужного набора:
Код:
if (ltrim($str, "a..zA..Z") == "") {
echo "Строка содержит только латинские буквы.";
}
Я так понимаю это и предлагалось как основной вопрос холивара. На эту самую тему я кстати недавно написал пост, кому интересно могут ознакомиться.
Цитата: Proger_XP
Я думаю под "тупым поиском" не подразумевался цикл вида "for (i = 0; i < length; i++) if str == char ..." - речь скорее шла о функциях поиска подстроки (именно встроенных функциях) vs. регулярки. Вот ту действительно есть над чем подумать - регулярки почти всегда тяжелее обычной strpos хотя бы потому, что им нужна компиляция (особенно если регулярка вызывается в цикле и это язык вроде PHP, а не JS, который перекомпилирует регулярку каждый раз - то это весьма медленно).
Заезженный пример проверки на число (preg_match("^\d+$") vs. is_numeric) более-менее очевиден, но, например, без использования регулярок можно также определить, содержит ли строка символы из нужного набора:
Я так понимаю это и предлагалось как основной вопрос холивара. На эту самую тему я кстати недавно написал пост, кому интересно могут ознакомиться.
Заезженный пример проверки на число (preg_match("^\d+$") vs. is_numeric) более-менее очевиден, но, например, без использования регулярок можно также определить, содержит ли строка символы из нужного набора:
Код:
if (ltrim($str, "a..zA..Z") == "") {
echo "Строка содержит только латинские буквы.";
}
echo "Строка содержит только латинские буквы.";
}
Я так понимаю это и предлагалось как основной вопрос холивара. На эту самую тему я кстати недавно написал пост, кому интересно могут ознакомиться.
Это очень простой пример, тут да, от регулярки особого смысла нет. Спорить не о чем :)
регуларка - это райт-онли мракобесие, которое не спасают ни декомпозиция, ни комментарии. я лично считаю, что регулярные выражения - инструмент для текстового редактора, а для синтаксического анализа (в коде регулярки почему-то обычно используют именно в этом качестве) лучше использовать пусть простецкий и кривенький, но всё же специализированный парсер.
p. s. я так понимаю, реквестировался именно флейм? :)
p. s. я так понимаю, реквестировался именно флейм? :)