Откройте для себя parser combinators.

Во дают фанаты xml. Кстати, это ни разу не регулярные выражения.

Ну и прочие генераторы парсеров.

Это чудо с минимальными изменениями можно просто накалякать на любом языке, так зачем создавать новый?

На C++ нельзя. Доказано boost::spirit.

Пусть это выглядит как-то так

Поиск подстроки (strstr, или как оно в твоём языке) пробовал использовать? Попробуй.

Я предлагаю либу, которая будет из указанного кода делать обычный регексповский мусор.

Идея недурна, но если требуется соблюсти максимальную удобочитаемость, то и выражения надо писать на самом удобном и человечном языке, то есть на русском.

{
  ПРОПУСКАТЬ_ПОКА_НЕ_ВСТРЕТИМ("\"");
  СОБРАТЬ(ЗНАКИ);
  ПРОПУСКАТЬ_ПОКА_НЕ_ВСТРЕТИМ(">");
  СОБРАТЬ(БУКВЫ);
}

Ты хотел сказать на эсперанто?

делать обычный регексповский мусор.

Зачем тебе регекспы, если они упрощаются до обычного while()?

Ну блин.
Это я предложил примитивнейший пример.
Ну! Не тупите!

Тупишь здесь пока что ты.

И скобочки, скобочки перевести. НАЧ_БЛОК и КОН_БЛОК.

{
  skip_until("\"");
  cut_out(LITERALS);
  skip_until(">");
  cut_out(LETTERS);
}

я всегда думал что регулярные выражения придумали для того чтобы не надо было писать такие скрипты

осиль phantomjs, хватит уже парсить html регулярками.

На C++ нельзя. Доказано boost::spirit.

Какое это имеет отношение к спириту? В предложении ТС есть некий блок, переписав его на С++, получим вызовы функций skip_until, cut_out и т.д.

ЗЫ. Вообще регэспы и системы описания синтаксиса ЯП при некоторой схожестви, все же совершенно разные вещи.

html

К чёрту HTML. Причём он тут?

phantomjs

К чёрту phantomjs. Костыль для частных случаев.

Я предлагаю либу, которая будет из указанного кода делать обычный регексповский мусор.

Регексповский мусор нужен для сокращения кода. Хочешь развернуто разбирать текст, пиши ЭТО прямо в коде.

Это я предложил примитивнейший пример.

Вот примитивнейший парсинг IP-адресов с какого-то сайта, можешь переписать его в своём виде?

\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b

Гм. Пока не могу.
Если бы я уже сформулировал идею в достаточном для реализации виде, то я пришёл бы сюда не с таким тредом, а с ссылкой на либу и словами:«Кому надо — пользуйтесь, кому не надо проходите мимо».

Иногда удобно хранить подобные вещи где-то в конфигах, чтобы для мелких изменений не перекомпилировать проект.
Поэтому вариант с парсингом средствами языка неудобен.

Oh, shit... Зачем же проверку на диапазон забивать в само выражение? ИМХО, никто не мешает проверить после

\b(?:(\d+)\.){3}(\d+)\b

Эта дрянь не держится у меня в голове дольше 2-3 дней

Вот тут корень проблемы.

А давайте сделаем, пусть и более многословные, но понятные для неподготовленного человека регулярные выражения?

Хочешь «понятливые для неподготовленного человека регулярные выражения» — используй regexp'ы с ключём /x.

понятные для неподготовленного человека регулярные выражения

неподготовленный человек может идти варить борщ

На C++ нельзя. Доказано boost::spirit.

На C++ можно. Доказано Qt.

Гм. Пока не могу.

Я это к тому, что, если переписывать правила по регекспу, получится нечто вроде: http://pastebin.com/1g4xQTgu . Так что твой регексп по-хорошему должен иметь какие-то дополнительные функции, чтобы его код не разрастался до таких монстров.

не нужно же

регулярные выражения и так понятны

На C++ можно. Доказано Qt.

Два чаю этому джентельмену!

Я понимаю это.
Я ведь не предлагаю делать «расшифровку» регулярок для людей.
Я предлагаю делать регулярки на базе другого «языка».
И этот язык не обязан быть в духе регулярок как они есть сейчас. Он лишь обязан быть в любом случае переводимым в регулярные выражения.

«Не нужно, нас и так всё устраивает»

/thread

а как же прекрасные однострочники на перле, если вместо регулярок будет такая простыня?

Я понял. Ты хочешь SQL только для регекспов. Но всё равно ненужно и неудобно.

XPath
/thread

SQL только для регекспов

Ну... Гм... Как-то так, да. Что-то близкое, наверное. Может быть и так.
:)
Я просто хочу чтобы я понимал что говорю машине.
Я за свою жизнь на машинном коде написал от силы 500-600 байт и больше не хочу. Для меня регулярки не лучше. Хочу ассемблерные мнемокоды!

XPath is used to navigate through elements and attributes in an XML document

И каким это боком к данному треду? Ты бы мне ещё pidgin посоветовал, ибо он XMPP поддерживает.

книгу Дж. Фридла уже советовали почитать?

Учи матчасть :)
PS: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml...

Ты упорот, да?
Ну каким боком тут вообще HTML?
Мы, вроде, про регулярные выражения говорим, разве нет?

Ну берёшь значит синтаксис регекспов и переводишь. То есть:
. => MUSTBE_ONE
? => MAYBE_ONE
* => MAYBE_ONE_OR_MORE
+ => MUSTBE_ONE_OR_MORE
[ => SYMGROUP_BEGIN
] => SYMGROUP_END

и так далее.
То есть ^([wx])([yz]) - будет как-то так
STRING_START
MEMORY_BEGIN
SYMGROUP
'w' OR 'x'
END_SYMGROUP
MEMORY_END
MEMORY_BEGIN
SYMGROUP
'y' OR 'z'
END_SYMGROUP
MEMORY_END

Только это совсем не то что ты начал предлагать. Потому что регулярное выражение - это декларация. Описание. А ты начал предлагать механизм. Механизмов же есть как минимум два, и лучше тебе в них не лезть.

Как-то все решили, что она не поможет.

мне помогла. ЧЯДНТ?

Может у тебя в этом проблема? В том, что ты совершенно не понимаешь СУТИ регулярных выражений? Что это не механизм, не инструкция, это декларация, шаблон?

Мне тоже помогла, но у меня не было изначального страха перед этими ужасными и непонятными символами.

Ты в примере парсишь html. Руглярками это не надо делать. Тем более, если ты вместо регулярок изобретаешь свой велосипед.
Не нравятся регулярки - описывай грамматику в БНФ и на ее основе делай парсер.

грамматику в БНФ

Она же ещё страшнее.

В студию врываются комбо-брэйкеры!

expr ::= expr '+' expr
       | expr '-' expr
       | '(' expr ')'
       | NUM ;

или

expr ::= expr '.' ID '(' actuals ')' ;

actuals ::= actuals ',' expr | expr ;

ave left-recursive!

получим вызовы функций skip_until, cut_out и т.д.

Как сделать без комбинаторов, например, альтернативы? В регулярках ЕМНИП они есть, значит и транслировать их нужно в комбинаторы. К примеру в spirit.

Вообще регэспы и системы описания синтаксиса ЯП при некоторой схожестви, все же совершенно разные вещи.

Мне что-то кажется, что область применения одного — подмножество другого.

поняв принцип работы регулярок, легко можно распарсить HTML. но двух минут чтения манула по регуляркам к твоему любимому ЯП для этого явно недостаточно

Ну как-то так, НО!
Дословный перевод оставит в силе мозголомность конструкции плюс добавит ей длины. Т.е. в итоге получится может даже ещё хужею

А комментарии в выражениях использовать что мешает?