А разве обычный Replace тебе обнаружит такое, нифига -- нашел любой IF и тупо его заменил. Так вот задача была не менять того, что уже заменено.

Если ты решишь только эту задачу, то опять получишь "Мультистрочная замена глючит".
Ну типа: "написал же в ReplaceList, что 153=Много, а у меня получилось Мало3 "

Собственно, я так и написал

------------ Дoбавленo в 15.31:

Про "обычный" я и не говорил
Говорил, про как бы "супер пупер правильный"

Но если сначала поставить замену 153, а потом 15, то такого не будет. Те условие, что надо ставить замены в убывающем порядке остается, и надо копать в сторону супер-пупер сортировщика

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

Как распарсишь строку 153215 при заменах


Семантику сам придумывать будешь, или возьмешь некий стандарт
Повторюсь, я ни на чем не настаиваю, а просто предостерегаю: стоит ли оно того.
Сам же видишь - один раз ты уже людям удружил, и получил диспуты про автоматизм.

А фиг его знает, что тут должно получиться на выходе
Ну и как оно должно разбираться

Дык, собственно, все текстовые языки программирования занимаются очень похожей фигней...
Есть входной длинный текст из буковок, и они на этапе лексического анализа разбивают его совершенно однозначно на логические фрагменты, называемые лексемами.
Далее есть разница: ЯВУ передают эти лексемы на синтаксический анализ, а мы (к примеру) делаем "замены"

Наверное, можно предположить, что эти правила однозначного разбиения являются неким стандартом. Потому что вообще все ЯВУ так делают де-факто (может быть кроме фортрана и форта - эти языки появились исторически вообще раньше понятия лексический анализ)

А про правила я уже говорил. Левая часть является определением лексемы (в ЯВУ там стоит более общее регулярное выражение), и выбирается лексема МАКСИМАЛЬНОЙ длины (т.е., для ELSEIF стопудово принимается именно он, а не ELSE). При одинаковой длине лексем (в нашем упрощенном случае - совершенно не актуально) - первый в списке.

Если исходить из этих правил, тогда 153215 -> (153)2(15) -> Тьма2Мало
Смотрится не очень умно... Дык и конкретные "определения лексем" особо умными не назовешь.
Но на абсолютно любой бред всегда есть совершенно однозначный ответ.

BTW: обычно в описаниях ЯВУ лексический анализ (в отличие от синтаксиса) сопровождают кучей словесной шелухи... А вот в стандарте C – правило «самой длинной лексемы» написано прямым текстом.

Но если исходить из этого и вот этого

достаточно поднять 153 на самый верх, а 3 и так в самом низу. Собственно, получается то же самое, что и с двумя предыдущими. Те получается, что надо использовать сортировщик лексем и самые длинные загонять наверх, а дальше в порядке убывания. Но ведь так и делали раньше вруччную. Кстати, а у тебя есть реализвция хорошего алгоритма обратной цифровой сортировки

В этом примере может и получается, а вообще говоря - нет.
Например такая модификация:

Как распарсишь строку 3153215 при заменах

В "типа общепринятых" правилах это СреднеМного2Мало

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

Зачем парсить то, что уже прошло замену?

А, не проще ли принять правило:"Кто выше тот и прав"
Есть жертва 3153215
Если в списке замен указано первым 15=3;, значит ищем все совпадения и совершаем замену. Получаем 33323
Если в списке замен указано вторым 33=15;, Значит ищем все совпадения и совершаем замену. Получаем 15323
Если в списке замен указано третьим 32=15;, значит ищем все совпадения и совершаем замену. Получаем 15153
Если в списке замен указано четвёртым 15=3;, Значит ищем все совпадения и совершаем замену. Получаем 333

Так оно сейчас так и работает Ты лучше посмотри, что нужно было TC

Повторюсь - я ни на чем не настаиваю
И ничего не придумываю.
Но могу рассказать (потому что случайно знаю), как делают типа "обычно".

А парсили-то в обоих примерах совершенно одинаково.
Исходная строка выбирается посимвольно СНАЧАЛА - отстегивается кусочек текста максимальной длины, подходящий под какое-то из определений (типа самая длинная лексема).
Отстегнули - делаем то же самое с остатком. Ну типа продолжаем... Не нашли лексему - продергиваем одиночный символ (в примерах это была двоечка).

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


Можно принять любое соглашение, лишь бы оно точно было известно всем остальным.
Предпочтительней - определяемое минимальным количеством словесов.

Полностью согласен с nesco - сегодня это просто "много замен по порядку"
Чего проще-то - переводи название элемента дословно.

Хватает ли этой (предельно простой) семантики - вопрос обсуждения...
Лично моя точка зрения - сооружать лексический анализатор только ради замен... Не царское это дело. В том смысле, что результат не стоит затрат. Вот полноценный сканер - может быть... Если не требовать супер быстродействия.
В общем, воровать - так миллион

А может оставить MultiReplace в покое, а сложными заменами пусть занимается RE_Replace?

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

Больше будет.
Путь в ад вымощен благими намерениями.