Передача функции через строку

[/dev/random]

проще уж организовать пайп с каким-нибудь интерпретатором (можно взять Python) и передать эту строку ему, получить и обработать результат.

Проще взять что-то вроде Lua, интерпретатор которого является _библиотекой_. И никаких пайпов не надо.

[AsMasteR]

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

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

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

расчитывать не прейдётся, я планировал резирвировать для этих целей строку фиксированной длины, а место после рабочих команд занупить,

предварительно позаботившись о способе возвращения из шелла итогового значения,

перед переходом в асм вставку записываваем адрес ячейки памяти, а последняя команда в строке jmp адрес+1 (образно т.к. будет разница при работе с 16,32,64 системами)

регистры нужно будет сохранить

А что хоть одна прога на асме работающая с регистрами обходится без этого??

Проще взять что-то вроде Lua, интерпретатор которого является _библиотекой_. И никаких пайпов не надо.

Респект!! Действительно хороший вариант, это позволит легко расширять функционал программы, в отличии от самодельного интерпритатора на си, который я собственно сейчас и пишу..

[serzh-z]

Респект!! Действительно хороший вариант, это позволит легко расширять функционал программы, в отличии от самодельного интерпритатора на си, который я собственно сейчас и пишу..

Эээ... Стоит всё же определиться. Передача функции через строку

[RasenHerz]

что-то я тоже не пойму чего надо автору - то его не устраивает использование интерпретаторов(а LUA - интерпретируемый язык), то он радуется совету их использовать.
в общем, AsMasteR, определитесь чего вам надо.

[drBatty]

Дональда Кнута давно уже читал, было помню.. дык там алгоритмы, а алгоритм я вроде вверху написал, мне синтаксис нужен. А K&R не что иное как спецификация (если ошибаюсь, прошу прощенья)..
Нет, я конечно могу ассемблерную вставку сделать, но неудобно будет.

классическая задача, K&R это конечно описание языка, но эта задача там как пример(вроде-бы)
реализация проста - строится дерево, например (a + b) * c
----*
---/--\
--+---c
-/--\
a---b

ну и обходите его по всякому(в зависимости от обхода будет и прямая, и обратная нотация)
обходить можно функциями, узлы хранить в структурах.. В общем классика. В самом языке Си такого нет, в х86 ассемблере - тоже. Про Java не знаю.

[drBatty]

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

хорошо. сделайте массив указателей на функции(каждая функция - действие(умножение, сложение), или число(переменная).
далее

Код: Выделить всё

for(;;)
{
 f = *a++;//получаем указатель на текущую функцию
 if(!f) break;//если это NULL, то расчёт закончен
 f();//выполняем текущий оператор
}

операторы между действиями нужно хранить в стеке.
к примеру (a + b) * с
a ------- push()
b ------- push()
+ ------- sum()
c ------- push()
* ------- mul()

надеюсь идея понятна

в отличие от вышеперечисленного это С, а не что-то другое.

[AsMasteR]

что-то я тоже не пойму чего надо автору - то его не устраивает использование интерпретаторов(а LUA - интерпретируемый язык), то он радуется совету их использовать.
в общем, AsMasteR, определитесь чего вам надо.

Да, по этому поводу у меня сомнения. Действительно я не хотел прибегать к интерпритаторам, и возможно в последствии вынужден буду отказаться от этой идеи.. Но простота этого метода позволит выстроить красивую модель программы в целом. Вчера прочитал спецификацию луа. Некоторые моменты в спецификации языка меня неустраивают (В частности работа оператора # и отсутствие типизации при объявлении..) но это поправимо. Скорость работы (не смотря на то что разработчики заявляют, что это самый быстрый инт. язык ) оставляет желать лучшего.. Но(!) самореализация интерпритатора под си, будет работать ещё медленнее(опять же со слов на форуме Луа).

в отличие от вышеперечисленного это С, а не что-то другое.

идея хорошая. что то подобное делал, когда пытался писать свою ос(в итоге увидел, что все мои идеи уже реализовал Линус )..
системные функции работать будут быстрее, чем просто си. только увы программа потеряет свою наглядность, а на этапе проектирования архетектуры программы, нужна наглядность. Когда алгоритм программы будет окончательно разработан и протестирован, скорее всего прибегну к этому методу. (А именно буду испоьзовать системные функции)

[NickLion]

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

А одно другому мешает? Кажется kamre и я упоминали, что можно строить дерево вычислений на основе выражения, записанного налядным образом. А затем считать быстро, не разбирая строк. Таким образом исходные данные - нагляды, вычисления - быстрые. Затраты на написание + отладку - 3 чел*часов, если не отвлекаться особо, 1 чел*день, если в релаксе.

[drBatty]

системные функции работать будут быстрее, чем просто си.

почему системные? я про ваши функции. идея следующая:
разбиваем строку на кусочки, строим дерево. потом обходим дерево, причём каждый терм записываем в линейный массив. а потом этот массив "выполняем", точнее выполняем каждый терм из массива

[AsMasteR]

почему системные? я про ваши функции

а похоже на системную интерпритацию аппаратных прерываний..
"выполняем"
не совсем понятно как здесь работает команда push() при том, что а в с переменные, а не константы..

[/dev/random]

Скорость работы (не смотря на то что разработчики заявляют, что это самый быстрый инт. язык ) оставляет желать лучшего..

С точки зрения скорости _выполнения_ это действительно самый быстрый интерпретируемый не-JIT язык, но немаленькое время уходит на конвертацию скрипта в байткод. Поэтому, если возможно, это стоит сделать один раз, а потом вызывать уже сконвертированную функцию (если, конечно, у вас одна и та же функция вызывается несколько раз).

[frp]

Синтаксический анализатор можно написать на голом C или C++ за десять минут. Если что, то могу скинуть код с комментариями.

[Serg79]

Синтаксический анализатор можно написать на голом C или C++ за десять минут. Если что, то могу скинуть код с комментариями.

Ты его к своему посту прикрепи в виде архива, может кому понадобиться.

[RasenHerz]

AsMasteR, советую обратить внимание на QScript - скорость работы на достойном уровне, отсутствует типизация переменных, к плюсам можно отнести чрезвычайную простоту использования.

[drBatty]

а похоже на системную интерпритацию аппаратных прерываний..
"выполняем"

читаем очередной указатель на функцию, и вызываем эту функцию(никаких прерываний, железа и системы!)
для каждого действия своя функция(умножение, сложение, и т.д.)

не совсем понятно как здесь работает команда push() при том, что а в с переменные, а не константы..

вот тут от задачи зависит. можно просто затолкать формулу в дерево, затем развернуть в массив и "выполнить", а можно поступить иначе, преобразовать дерево. например:
X * 0

---*------------0
-/---\---- =>
X---0

ну и многие другие правила(штук 5), тогда мы упростим формулу, и будем по неё быстрее считать. (хотя дольше преобразовывать).
и push() в данном случае будет работать по разному, если мы берём простой метод, без упрощения, то на этапе выполнения, константа 7 и переменная X равная 7 эквивалентны(X псевдоним 7), а если мы упрощаем, то заталкиваемое X в стек может быть не только константой, но и функцией(той-же самой, только рекурсивной). Вобщем задачка вовсе не на 5 минут, это видно хотя-бы по числу принципиально разных решений в этой теме. Самое смешное, что тут нет лучшего, они все хороши, каждый в своём случае.

[NickLion]

Вот переписал по-быстрому. Почти не тестил, так что отсутствие ошибок не гарантирую.

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

[RasenHerz]

Вот переписал по-быстрому. Почти не тестил, так что отсутствие ошибок не гарантирую.

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

а можно архив не .rar? лучше .tab.gz или .tar.bz2 .

[NickLion]

Вообще-то, это 7z, но он не прикрепляется, посему добавляю .rar в конец имени

[Serg79]

Вот переписал по-быстрому. Почти не тестил, так что отсутствие ошибок не гарантирую.

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

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

[Женя Подсыпальников]

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

возможность выполнять динамический код

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

О... Это всегда интересно - обойтись безо интерпретаторовых...

Коли есть Редактор твоего приложения (процесс 1) -
можно даже скомпилить неки функции (формулы) в неку библиотеку их -
для Исполнения твоего приложения (процесс 2),

подобно тому, как это бывает в некоторых известных продуктах,
запускающих некоторый компилятор (к примеру, редактор Анюта) -
для других, использующих компилят (к примеру, строка консоли, запускающаяя процесс с параметрами) ...

А в Исполнении - пусть будет функция обращения к редактированным и компилированным формулам -
по имени ли индексу... Некоторые процесс или функция, ведь, умеют возвращать ответы.

Одним из безопасных примеров -
является техника позднего связывания в СОМ, например, конечно...

А шобы не крякало попусту - поместить замес в try{...} - всегда хорошо

[RasenHerz]

О... Это всегда интересно - обойтись безо интерпретаторовых...

Коли есть Редактор твоего приложения (процесс 1) -
можно даже скомпилить неки функции (формулы) в неку библиотеку их -
для Исполнения твоего приложения (процесс 2),

подобно тому, как это бывает в некоторых известных продуктах,
запускающих некоторый компилятор (к примеру, редактор Анюта) -
для других, использующих компилят (к примеру, строка консоли, запускающаяя процесс с параметрами) ...

А в Исполнении - пусть будет функция обращения к редактированным и компилированным формулам -
по имени ли индексу... Некоторые процесс или функция, ведь, умеют возвращать ответы.

Одним из безопасных примеров -
является техника позднего связывания в СОМ, например, конечно...

А шобы не крякало попусту - поместить замес в try{...} - всегда хорошо

чего уж мелочиться, давайте напишем виртуальную машину считающую формулы...

[NickLion]

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

Бинарные + - * / ^ (степень), унарные + -, круглые скобки, функции - любые уже прописаны - стандартные математические (sqrt, pow, ln, lg, sin, cos, tg, ctg, ... ).

О... Это всегда интересно - обойтись безо интерпретаторовых...
(skipped)
Одним из безопасных примеров -
является техника позднего связывания в СОМ, например, конечно...

А шобы не крякало попусту - поместить замес в try{...} - всегда хорошо

COM построено на технологии виртуалных вызовов, а не динамической компиляции. А try от доступа по левому, но корректному адресу не спасет. В общем такое использовать - в крайнем случае, для особо критичных мест. А еще лучше сделать так, чтобы такого не требовалось.
PS если Вы про динамически подключаему библиотеку, а не динамический код, то извините Я не против динамически подключаемых либ (в настройках имя либы+имя функции), но против динамического кода (допустимо как антиотладочный прием, полиморфный движок, но не в данном случае).

[kamre]

чего уж мелочиться, давайте напишем виртуальную машину считающую формулы...

Так уже есть такие виртуальные машины
Вот пример на .NET, считающий формулы: Частые вычисления по неопределенной формуле!!!
И он уделал пример на C++ в 20 раз А все потому, что на C++ формулы считались интерпретатором (вроде того, что выше предлагали), а в .NET варианте свое дело сделал JIT компилятор, получился native code, и уже он вычислял значения формулы. И все это в runtime.

[serzh-z]

Вот пример на .NET, считающий формулы: Частые вычисления по неопределенной формуле!!!

Уж не знаю в каких попугаях считают на RSDN, но последние лет пять у них всегда и во всём C# и .NET уделывает любые другие языки и платформы... Не смотря на это уделывание, их шарповым клиентом RSDN@Home, ещё во времена начала эпохи уделывания, я так пользоваться и не смог, по причине его МЕГАтормознутости, по сравнению со всеми другими приложениями, включая веб-браузеры.

[RasenHerz]

чего уж мелочиться, давайте напишем виртуальную машину считающую формулы...

Так уже есть такие виртуальные машины
Вот пример на .NET, считающий формулы: Частые вычисления по неопределенной формуле!!!
И он уделал пример на C++ в 20 раз А все потому, что на C++ формулы считались интерпретатором (вроде того, что выше предлагали), а в .NET варианте свое дело сделал JIT компилятор, получился native code, и уже он вычислял значения формулы. И все это в runtime.

в этом ничего удивительного - интерпретирование всегда медленнее чем JIT-компиляция. думаю, если бы вычисления производились с помощью Java, то они были бы быстрее .NET'овских раз в 20 =)))

[Женя Подсыпальников]

А еще лучше сделать так, чтобы такого не требовалось.

Еслив я клиент библиотеки формул
некоторого свободного написания их кода,

то кто-то-сь - наверняка знает, "как оно там всё сделано"...

[NickLion]

Еслив я клиент библиотеки формул
некоторого свободного написания их кода,

то кто-то-сь - наверняка знает, "как оно там всё сделано"...

Извините, но можно на русском это же сказать? Или на украинском, английском ?

[Женя Подсыпальников]

Извините, но можно на русском это же сказать? Или на украинском, английском ?

Простите...
(Оно - просто,) попробую ещё так:

динамически подгружаемый код формулы
мог быть скомпилирован (раз он существует),

но текст формулы к компиляции делан, возможно, не мною...

Вот почему - я бы запускал такой код в try{..}