Есть такой код в StrMask:

function _StrCmp(Str,MskChar):boolean;
begin
while (Str^<>#0)and(Msk^<>#0) do begin
if Msk^ = '*' then begin
if _StrCmp(Str,Msk+1) then begin
Result := true;
exit;
end;
end else if Msk^ = '#' then begin
if Str^ in ['0'..'9'] then Inc(Msk)
else break;
end else if (Msk^ = '?')or(Msk^ = Str^) then Inc(Msk)
else break;
Inc(Str);
end;
Result := (Str^ = #0)and(Msk^ = #0);
end;

Собственно если '#' то 1 цифра..а если диапазон цифр нужен? например > 1 ?
Можно как-то в данный код добавить такую функцию?

Gunnman, имеется в виду логика: "#" -- одна любая цифра, а скажем "`#" -- несколько подряд идущих цифр ?

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

Неплохо и универсальный сканер сделать...
Потом уже и универсальный парсер синтаксиса...

Galkov, Меня хватает только на пару строк Вот этих: code_33048.txt

Леонид, "#" -- одна любая цифра, а скажем "`#" -- несколько подряд идущих цифр - совершенно верно!

Спасибо за код!

Galkov, не нужно никаких новых синтаксисов, все уже есть давно
Gunnman, если твои задачи не получается решить с помощью StrMask, попробуй RE_Search, RegularExpressions. Решить ту же задачу с его помощью будет сложнее, чем со StrMask, но зато функционал намного шире.
Например, задача из первого поста на регулярках решается такой маской: "^d+$", где "^" - значит, что последовательность должна начинаться с начала строки, "d" - любая цифра, "+" - означает, что "d" может повторяться 1 и более раз (т.е. 1 и более цифр в строке), "$" - означает, что на цифрах строка и заканчивается.

Не смешите мои подковы.
Лучше книжки почитайте. Прежде, чем произносить суждения про "синтаксис" - лучше знать, что это такое.

Сколько ни вчитывался, не понял, почему нельзя назвать правила построения выражений для RegExpr синтаксисом. Galkov, если не затруднит, объясни, пожалуйста.

"Правила построения выражений для RegExpr" можно назвать синтаксисом.
Которому на вход необходимо уже не буквы подавать, а лексемы.
А та хренька, которая из входного потока букв делает поток лексем -- называется лексическим анализатором, или сканером.

Однако вопрос не стоял о том, чем следует называть "правила построения чего-то там", а об анализе некоторого входного текста.
И Ваше утверждение, Assasin, состояло в том, что все уже давно есть, и никаких новых синтаксисов Вам не надо.

Нету.
Настоящего (чуть более сложного, чем установление факта присутствия чего-то там, где-то там) анализа, с помощью приведенного Вами списка элементов -- не сделаешь.
Конкретно: Вы не сделаете MathParse на элементах RE_Search, RegularExpressions.
А уже эта беседа -- вовсе не на 5 минут.
Именно поэтому я и предложил Вам книжки почитать. Перед утверждением о нужности/не нужности чего то там. А не Wikipedia.

А, это-то верно, ничего универсального не существует и к этому стремятся. Это тема философская, и действительно не на 5 минут. Я то хотел сказать, что для большинства возникающих в реале задач регексов достаточно, и, применительно к этому топику, с моей точки зрения, никаких новых синтаксисов не нужно, хватит и RegExpr - достаточно коротко и понятно.

В большинстве случаев не требуется селектор от 3-х до 8-ми (к примеру) символов, из определенного множества (к примеру 3..6). И, в случае нахождения таковых (причем: не стоящих в "рекурсивных комментариях") -- обработать как-то 4-ю и 5-ю цифру.

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

Вот мне надо было "человеческую" формулу (с пользовательскими именами переменных) преобразовать в пригодную на съедение для MathParse.
Да, базовыми элементами это еще можно сделать (и делал, до его доработки).
А вот если бы в синтаксисе нашего MathParse допускались БЫ строковые переменные (почему бы и нет, если как аргумент какой-то функции), то было БЫ - фигу с маслом.
И не помогли бы ни RE_Search, ни RegularExpressions

---

Ведь что я говорил-то: просто универсализировал по максимуму "хотелось бы". И не более того.

Galkov
Да.
Всё правильно.
Проблема существует.
По мере возможности надо её минимизировать, вовсе её снять нельзя.
Нельзя цепляться за мысль, что всё вроде устаканилось и слава богу, а какие то нововведения породят разброд и смуту.
Одно время я вообще хотел отказаться от HiAsm.
Потом приспособился, из IC стали рождаться "укрупнённые" компоненты.
Ведь в природе как?
Где чего убудет, то с другого бока - прибудет.
Ведь в среде разработки Borland Delphi7, или NET Framework есть минусы по сравнению с HiAsm.
Зависит, - с какой позиции разглядывать.
Моё мнение, что подавляющее бешенство задач типичны, отличие в нюансах, и стоит делать "укрупнённые" компоненты, может быть несколько однотипных с какими то отличиями.
Это сложнее, чем перетащить компонент из какой то среды разработки в HiAsm.
Но как говорил Остап Ибрагимович, - "Киса, - мы же художники!".
Лучше иметь переполненную палитру, чем бедную. Лучше больше, чем никогда.

Угу.
Просто хотелось бы добавить, что у этой проблемы есть своя сложность.
Примерно уровня MathParse (это не точный расчет, а оценка).
Не простая, но вовсе не неразрешимая.

Это точно.