Производительность - это вопрос длины строки. Интерпретируемые языки почти всегда работают медленнее, чем скомпилированный C-код для оценки арифметических выражений. Но не так много программ проводят большую часть своего времени, занимаясь арифметикой, поэтому большую часть времени это не имеет значения. Также имеет значение, анализируете ли вы выражение каждый раз, когда вы его оцениваете, или (как это кажется более вероятным из того, что вы говорите), анализируйте его в какую-то промежуточную форму.
Невозможно судить по тому, что вы сказали, будет ли это важно для вас, или как быстро вы напишите переводчику, но я не ожидаю, что это будет лучше, чем в 10 раз медленнее, если потратить время. Оценка выражений обеспокоена. Первые попытки интерпретации были намного хуже.
Что касается этой промежуточной формы - обычно для начала нужно использовать алгоритм Дейкстры "shunting-yard", чтобы преобразовать ваши инфиксные выражения в обратную польскую форму. Это дает вам последовательность «символов», «байтовых кодов», называете их как вам угодно, и легко написать оценщик выражений для этой формы - каждый оператор просто извлекает свои операнды из стека, выполняет операцию, затем выталкивает результат на стек, пока окончательное значение выражения не будет единственным, что осталось в конце. Числовые литералы и имена переменных похожи на «операторы», которые не выдают операндов и выдвигают свои значения.
[Редактировать - в зависимости от того, кто ваши пользователи, для вашей программы может быть целесообразным взять этот текстовый файл, сгенерировать из него программу на C, запустить компилятор и затем запустить результирующую программу (или открыть и вызвать полученную программу). DLL). Очевидно, что это зависит от множества специфических для системы вещей (например, от устанавливаемого компилятора), и выражения нужно будет оценивать достаточно много раз, чтобы преодолеть издержки компиляции.]