Цитата
процедурка "TEST" для ввода ф-ии сохраняла результат из переменных x y (к примеру было введено "x+y" и она должна хранить этот результат !не в формате стринг!, без знания значений x y.
а ф-ия "BBog_xy" зная значения x y както обращалась к гдето хранившемся результате из процедурки "TEST" подставляла значения x y и выводила ответ.
Ты для себя-то реши, в каком формате и что ты хочешь хранить, а то получается "пойди туда, не знаю куда, принеси то, не знаю что..." (С)
Задачу формализуй: что за функция, где и что известно, к чему доступ должен быть, к чему - нет, КАК ВЫЗЫВАЕТСЯ вычисление значения функции с тем или иным параметром...
И чем не устраивает то решение, которое озвучено выше?Навскидку могу дополнительно предложить введенную функцию опять же парсить, загонять в дерево: узлы - операции, или операнды, над которыми эти операции должны выполняться, (или перегонять в ОПЗ - обратную польскую запись, и хранить в виде списка, но тут будет засада с тем, что ты замучаешься реализовывать И вычисления простых арифметических операций, и вычисления функций от одного/двух/трех аргументов) но там, где будут потом подставляться значения аргументов - хранить указатель на какой-то элемент массива аргументов... А потом, при вычислении функции, передавать параметром в функцию вычисления сам массив аргументов. Предупреждаю сразу: в итоге все равно сведется к тому, что и было уже найдено тобой, только ты реализуешь этот велосипед сам. А потом поймешь, что НЕЛЬЗЯ вычислять что-то, что-то вводя, но ничего об этом не зная, в каких-то точках... Я понятно объяснил?
Есть несколько готовых классов-парсеров (ООП, естественно), но пока не будет уточнения о том, какие могут быть функции, и что на каком этапе тебе известно, а что надо скрыть, и что когда вычисляется - ссылок не будет.