Auf Anregung aus dem Chat habe ich mal die Funktionen gepostet, die ich für meinen Interpreter erdacht habe. Der Algorithmus ist allerdings im Vergleich zu Profi-Interpretern etwas langsam, dafür aber stabil:

Quellcode:
char CEsosParser::GetChar()
{
    char c;
    m_pFile->get(c); // m_pFile ist ein Zeiger auf ifstream
    return c;
}

char CEsosParser::PreviewChar()
{
    char c;
    m_pFile->get(c);
    m_pFile->putback(c);
    return c;
}

bool CEsosParser::IsTerminator(char c)
{
    if(c == '\n' || c == '\r') m_line++; // m_line ist die aktuelle Zeile, die gelesen wird
    return (c == '\n' || c == '\r' || c == EOF);
}

int CEsosParser::ParseDirective()
{
    int result = -1,
        *exc = NULL,
        i = 0,
        j = 0,
        counter = 0;
    bool end = false,
         match = false;
    char c;
    exc = new int[m_directivesSize]; // m_directivesSize = Anzahl der Elemente im Array
    for(int x=0; x<m_directivesSize; x++) exc[ x ] = 0;
    do
    {
        c = GetChar();
        do
        {
            if(exc[ j ]>=0)
            {
                if(c == m_directives[ i ][exc[ j ]]) // m_directives = char* Array mit den Direktiven
                {
                    if((counter==m_directivesSize-1) && (exc[ j ]==static_cast<int>(strlen(m_directives[ i ])-1)))
                    {
                        end = match = true;
                        result = j;
                    }
                    exc[ j ]++;
                }
                else if(IsTerminator(c) || c==' ')
                {
                    end = match = true;
                    result = j;
                    PutbackChar(c); // Inline Methode, packt das Zeichen c in den Stream zurück
                }
                else
                {
                    exc[ j ] = -1;
                    counter++;
                }
            }
            i++;
            j++;
            if(i == m_directivesSize)
            {
                i = j = 0;
                match = true;
            }
            if(counter==m_directivesSize)
            {
                result = -1;
                match = end = true;
            }
        }while(!match);
        match = false;
    }while(!end);
    delete [] exc;
    return result;
}

void CEsosParser::ParseErrorMessage()
{
    char c;
    // Trim left side of error message
    while((c = GetChar()) == ' ');
    PutbackChar(c);
    // Show error message until line termination
    while(!IsTerminator(c = GetChar())) cerr << c;
    cerr << endl;
}

Die Vorgangsweise ist simpel: Für jede vorhandene Direktive im char* Array m_directives[] wird zuerst dynamisch ein Ausschlußfeld (exc[]) erzeugt. exc[] besitzt formal zwei Zustände: -1 und != -1. Falls exc[] -1 ist, wird die vom Index passende Direktive beim nächsten Durchlauf nicht mehr untersucht, da sie vorher bereits nicht mehr der interpretierten Direktive entspricht. Ist exc[] != -1 (also >= 0), dann ist der Wert gleich dem Zeichenindex der Direktive.

Also wenn es 2 Direktiven im m_directives[] Array gibt, wird exc[2] erzeugt und beide defaultmäßig mit 0 initialisiert. exc[0] = 0 bedeutet: 1. Direktive, Zeichenindex 0 (1. Zeichen) der Direktive. exc[1] = 5 würde bedeuten: 2. Direktive, Zeichenindex 5 (6. Zeichen) der Direktive. exc[1] = -1 bedeutet dagegen, daß Direktive 2 nicht mehr der gesuchten Direktive entspricht (weil irgendwo vorher ein Zeichen nicht mehr übereingestimmt hat).

Nun wird jedes Zeichen aus der Datei gelesen. Ein vorgeschalteter Identifikator (hier als Methode nicht gepostet) erkennt erstmal das Zeichen '#' und wechselt in den Zustand der Direktiven-Interpretierung (durch Aufruf der Methode ParseDirective()). Nun wird jedes Zeichen bis zu einem Linefeed oder bis zum Ende der Datei (EOF) gelesen und mit jedem Zeichen jeder Direktive verglichen, die in exc[] beschrieben ist. Wenn irgendwann einmal nur noch ein exc[] != -1 ist und alle anderen exc[] == -1, dann "weiß" die Methode, daß es nur noch zwei Möglichkeiten gibt:

a) Die momentan interpretierte Direktive ist tatsächlich die gesuchte Direktive oder
b) Die interpretierte Direktive stimmt auch nicht (wegen Schreibfehlern usw.)

Daher vergleicht die Methode ab da automatisch die Länge der letzten in ecx[] beschriebenen Direktive mit der Anzahl der gelesenen Zeichen. Stimmen beide irgendwann mal überein, dann vollzieht die Methode frech einen Preview auf das nächste Zeichen. Ist das nächste Zeichen ein Terminator-Zeichen ('\n', '\r' oder EOF) oder ein Leerzeichen ' ', dann "weiß" die Methode, daß die aktuell interpretierte Direktive mit der aktuelle aus exc[] verknüpften Direktive aus dem Array übereinstimmt. Ab da könnte die Methode sagen: Ok, ich habe eine gültige Direktive gefunden und zwar die Direktive mit dem Arrayindex x.

Schlauerweise habe ich es aber so eingefädelt, daß auch dann eine gültige Direktive gemeldet wird, wenn das Preview-Zeichen kein Terminator oder Leerzeichen ist, sondern irgendein anderes Zeichen. So kann man nämlich beispielsweise schreiben im Text:

#error Abbruch, da blablabla...

oder auch

#errorAbbruch, da blablabla...

Anders sieht es aus, wenn alle exc[] == -1 sind. Dann ist nämlich die interpretierte Direktive falsch und die Methode gibt einen Parsing-Error zurück.

Im Falle von #error geht der Parser dann in den Zustand der Fehlermeldungs-Darstellung über und gibt alle Zeichen direkt hinter #error aus, um dann abschließend das Interpretieren zu beenden.

Die Fehlerparsing-Methode trimmt dabei alle linksseitigen Leerzeichen weg, so daß auch der Ausdruck:

Quellcode:#error                       Abbruch, da blablabla...

funktioniert.

Wie gesagt, daß alles bezieht sich jetzt auf das Direktiven-Parsing. Schlüsselwort-Parsing läuft dabei identisch ab, wobei ich dort allerdings nicht bei jedem Schlüsselwort solche Späße wie

#errorAbbruch

erlauben werde. Bedeutet: Man darf schrieben if(...) oder if (...), aber nicht intVar1, sondern int Var1!

Tja, soweit meine Gedankengänge. Wer nicht alles kapiert hat, aber fit im Codelesen ist, der kann ja mal nen Schreibtischtest durchführen und den Code Schritt für Schritt nachvollziehen.

Cu

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

1. ist das c++ code? (sieht für mich so aus aber kann ja auch was anderes sein)
2. was interpretiert der nun genau?

ich interessiere mich für etwas ähnliches, nämlich einen arithmetischen parser, der mathematische terme , z.b. 6*(7²+8²) berechnen kann. bisher habe ich einige lösungsansätze, aber es funktioniert noch nicht so richtig.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

Das sieht für mich auch ganz arg nach C++ aus....

Ich denke Kriz meint damit keinen Parser, sondern einen richtigen Interpreter (wie er ja auch geschrieben hat =).
Also der Code wird nicht in einem Compiler zu einer ausführbaren Datei kompiliert, sondern er wird direkt beim Ausführen "interpretiert"!
Das ist, soviel ich weiß, langsamer als kompilierter Code, aber nicht so umständlich, da kein Compiler erforderlich ist.
Ich glaube VB und teilweise Java sind Interpretersprachen, oder?

Ich kenn mich nicht wirklich damit aus...

cu
Matze

BattleTech-MOD:
http://bthl.unitedgaming.net/

Wuahr, wenn das nen gesamter Interpret ist fress' ich nen Besen!
Wozu besagter Code jetzt allerdings gut sein soll ist mir auch ... fraglich! =P

shielding people from their own stupidity is an evolutionary step backwards anyway.

/* God is dead!............Nietzsche */
/* Nietzsche is dead!......God */
/* Nietzsche is God!.......The Dead */

Zum Beispiel könntest du auf der Basis dieses Interpreters endlich mal die .sc-Dateien von HL zum Leben erwecken =)

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

was ist eigentlich der unterschied zw. strlen() und lstrlen() ?

1.es gibt size_t, 2.es int zurück; aber was noch?

lstrlen ist von microsoft, jedenfalls ist sein prototyp nicht in einem standartheader. ausserdem nimmt lstrlen auch unicode an.

strlen ist von c geerbt, diese funktion ist im ansi-standart von c definiert. was das mit dem lstrlen soll, weiss ich auch nicht, was es schon gibt muss man doch nicht nochmal programmieren.

@topic: der code sieht ja hochinteressant aus, und wenn das wirklich ein interpreter ist, dann wird er auch ganz schön nützlich sein.

nur fehlen uns infos, wozu der genau gut ist. interpretieren kann man allerhand.

und: interpreter sind langsamer als kompiler, denn das, was der kompiler zur kompilierzeit erledigt, macht der interpreter zur laufzeit ==> mehr rechenaufwand zur laufzeit ==> langsamer
wie das mit dem aufwand aussieht weiss ich nicht.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

@Levi: das ist auch nur ein teil eines interpreters, der für direktiven...

ich hab mal nen parser gemacht (mathematische terme und funktionen), ist ganz schön aufwendig, aber interessant ;)

This post was written using Opera 7.0 (http://www.opera.com)

Zitat:

Leviathan postete
1. ist das c++ code? (sieht für mich so aus aber kann ja auch was anderes sein)
2. was interpretiert der nun genau?

ich interessiere mich für etwas ähnliches, nämlich einen arithmetischen parser, der mathematische terme , z.b. 6*(7²+8²) berechnen kann. bisher habe ich einige lösungsansätze, aber es funktioniert noch nicht so richtig.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Zitat:

Kriz postete
(95% stabil)

This post was written using Opera 7.0 (http://www.opera.com)

5% instabil! :O

oder:
von 100 "2x²+2=y" 'Parsungen' sind 95 richtig und 5 falsch ..
is doch logisch =)

Another1

...relaxing..atm =)
... und Schweiz suckt!

Nö...bei 5 stürzt das Programm ab! =)

BattleTech-MOD:
http://bthl.unitedgaming.net/

Zitat:

Mazze postete

Ich glaube VB und teilweise Java sind Interpretersprachen, oder?

es ist zwar durchaus möglich vb-programme interpretieren zu lassen aber es steht nichts im Wege in Native-Code zu kompilieren und ich denke das dass auch zu 98% (eigene Schätzung) der Fälle gemacht wird.

Java ist definitiv eine Interpretersprache, auch wenn nicht der pure Quellcode interpretiert wird.

georg-wicherski@pixel-house.net | http://www.pixel-house.net/ - Coding Resource| http://www.google.de/

@Ferdi: Wobei aber auch der Native-Code sich nicht mit Recht Native-Code nennen sollte - der braucht noch reichlich Unterstützung von der VBasic Virtual Machine DLL. Hat Ähnlichkeiten mit der Abhängigkeit von MFC-Programmen von der mfc42.dll, andererseits kann man mit C, Pascal und so weiter ohne Probleme Programme schreiben, die wirklich ohne Dependencies auskommen. Mit VB nicht.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Zitat:

[RMen]OneStone postete
Java ist definitiv eine Interpretersprache, auch wenn nicht der pure Quellcode interpretiert wird.

das ist definitiv falsch, es hindert einem niemand daran, aus java quelltext oder bytecode nativecode zu erzeugen, es gibt sogar einige java-native-compiler.

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

Java ist nach der offiziellen Spezifikation von SUN eine Interpretersprache, dass es Native Compiler gibt weiss ich, und ist eine andere Sache. Ausserdem musst du nicht immer alles so kleinkarriert sehen, nur um mir zu schaden. Willst du nur alles, was ich poste, kritisieren? Such dir einen anderen!

georg-wicherski@pixel-house.net | http://www.pixel-house.net/ - Coding Resource| http://www.google.de/

Der ganze Sinn oder Unsinn über die Tatsache, daß Java interpretiert wird, liegt darin, daß Java auf UNICODE basiert. Da UNICODE aber nicht von allen halbwegs modernen Betriebssystemen dieser Welt unterstützt wird, muß eine Metasprache herhalten, die auf Standards basiert. Und der Java-Bytecode basiert nunmal auf Bytes (unglaublich =), also 8-Bit Sequenzen. Und da dieser Bytecode nunmal weder Maschinensprache noch sonstwas ist, brauchts eben einen Interpreter, der ihn für das OS übersetzt.

Native-Compiler für den Java Quellcode sind zwar fein, aber so nützlich wie ein Pickel am Arsch. Schließlich wurde Java entwickelt, um systemunabhängig zu sein. Ein Compiler zerstört diese Grundlage aber leider, da er für das OS arbeitet und nicht unabhängig.

Und außerdem ist es in Webseiten nicht gerade toll, wenn der Browser erstmal den Quellcode kompilieren müßte, um eventuell wegen ein paar Bugs zu melden, daß das Applet nicht funktionieren wird... Das kann zwar auch dann passieren, wenn die Java-VM des Browser noch aus Schnauzbarts Zeiten stammt und die neueren Befehle nicht kennt (alles schon erlebt!), aber das kommt selten vor.

Java ist aber selbst als Java nicht unabhängig! Per Definition ist Java erst dann eine systemunabhängige Sprache, wenn man das Swing Toolkit ausschließlich benutzt, da Java dann alle grafischen Bestandteile selber erzeugt und bereitstellt. Alles andere ist nur ein böser Hack in die Ressourcen der Ziel-GUI. Das wird btw. auch überall in allen besseren Java-Büchern fett hervorgehoben! Und Javas Konsolenausgabe ist nur eine nette Dreingabe, da sie in Webanwendungen eh nicht benutzt werden kann...

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

@TTT:
von daher hast du schon recht...aber interpretiert wird er dann nicht und darum ging es ja denke ich....

Wenn wir schon beim Thema Parser sind: Im Quellcode von RTTS ist ein recht flexibler formatunabhängiger Parser versteckt ;p

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hauptsache Werbung machen =)

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Klar - genauso wie Kriz ;p

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Für was mache ich denn Werbung???

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Zitat:

K:R-I)Z++
Crazykriz's Amazing Website

Another1

...relaxing..atm =)
... und Schweiz suckt!

Herr hilf... :D

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)