also ich habe folgendes Problem:
Ich habe einen rekursiven parser, der mathematische Ausdrücke (in Form von strings) rekursive durchrechnet, z.B. 2^(i+4*3/5+7/2)/5. Sprich ein etwas schlauerer Taschenrechner.
Das funktioniert auch gut und schön, ist jedoch, um damit beispielsweise eine Funktion (variable wird deklariert und dann durch Zahlenstring ersetzt) zu plotten viel zu langsam. Lässt sich das beschleunigen ? Z.B. indem der Parser irgendwie anstatt in eine Zahl zu parsen, eine Funktion erstellt (???), die sowas macht ? Dann müsste man einmal parsen und alles weitere würde beschleunigt von statten gehen.

Oder kann ich das compilermäßig beschleunigen (borland 5.5) ?
ASM muss ich nicht unbedingt verwenden, falls das eine Variante sein sollte...

Vielen dank für ideen !

Lässt sich das beschleunigen ? Z.B. indem der Parser irgendwie anstatt in eine Zahl zu parsen, eine Funktion erstellt (???), die sowas macht ? Dann müsste man einmal parsen und alles weitere würde beschleunigt von statten gehen.

Du kannst anhand der Formel einfach C- oder C++-Code erstellen, einen Compiler das Ganze als minimale DLL kompilieren lassen und sie laden. Hört sich umständlich an, ist aber imho recht flott realisiert.

class ParseDing{
   virtual double eval()=0;
};
class Summe:public ParseDing{
   ParseDing* links;
   ParseDing* rechts;
   double eval(){
      return links->eval()+rechts->eval();
   }
};
class Produkt...

damit kannste einen total übersichtlichen parsebaum bauen. der ist dann auch recht fix im interpretieren.

Daher meine frage:..
@Knivil: Wie genau meinst du das ? Im Sinne von Binärbäumen mit Zeigern auf das jeweils nächste Element ? Wo ist der Unterschied (evtl. Vorteil) zu Volkards Lösung ?

Mhh... Ok, wie wird so eine Parserklasse praktisch umgesetzt ?
Ich nehme an, ich baue eine Klasse

class ParseMathString {

public : 
    ParseMathSring( const char* MathString );
    double Evaluate();

private :
     char* MathString;
};

die dann in der evaluate Funktion den ParseTree baut. Wie handhabe ich den, sprich wie sorge ich z.B. dafür, dass ich ihn erneut abrufen kann. Die Lebensdauer der dort erzeugten ParseDings-Klassen ( siehe Beitrag von Volkard ) wäre ja nur entlang der Evaluate Funktion.
Macht man das, z.B. dann so :

typedef vector<ParseDing> Expression;

class ParseMathString {

public : 
    ParseMathString( const char* MathString );
    Expression evaluate();

private :
     char* MathString ;
     vector<Expression> evaluatedStrings ; 
};

dann müsste man irgendwie dafür sorgen, dass die ganzen Zeiger usw. noch gelten, oder ??

ich benutze zur Zeit die VCL vom Builder...

Wenn du das nicht unbedingt selbst schreiben willst, könntest du JclExprEval aus der JEDI Code Library benutzen. Die enthaltenen Klassen können einen Parse-Tree generieren.

Flex und Bison - werde ich ausprobieren.

EDIT:
Eine Frage dazu habe ich noch: Lässt sich der Code händisch einigermaßen erweitern ? Ich hätte zum Beispiel gerne die Möglichkeit Variablen (string name, double value ) in einer Datei zu deklarieren, sodass er diese erkennt und die entsprechenden Werte einsetzt. Das sollte aber nicht als eine Art Makro fungieren, sondern direkt im ParseTree mit vorhanden sein .
Ich sehe den Code ja, daher die Frage: ist das wirklich eine Arbeitsaufwandsreduzierung ?