Boost.Spirit Parser crasht mit Segfault -

[Sone]

seldon schrieb:

Du erwartest aber hoffentlich nicht, dass ich dir deine Hausaufgaben abnehme.

Niemals, das wäre nicht nur eine peinliche Schande, sondern außerdem ist das keine Hausaufgabe.

Danke für den Link!

[Sone]

Gut, was ich herausgefunden habe, ist dass die meisten LR-Parsergeneratoren Grammar-Files nutzen. Die sind komplex strukturiert; basil sieht gut aus. Sehe ich mir mal an.

[Kellerautomat]

@seldon: Du kennst nicht zufaellig eine Einfuehrung in Grammatiken und deren Grundbegriffe?

[Sone]

UltraGram ist klasse, und perfekt für meine Zwecke geeignet.

[Sone]

IIIIEEEEHH!!
UltraGrams Codegenerator produziert Code mit malloc/realloc/free!

Ich werde erstmal ein Viertelstündchen heulen. Darf sowas nicht jeden Tag machen.

[Sone]

Und was ist das bitte für ein OOP-Modell, in dem Klassen nicht mal ihre eigenen Abhängigkeiten bereitstellen? Jetzt muss ich einen Haufen Header einbinden -.-

[Sone]

Ich habe heute eine sehr wichtige Lektion gelernt. Acuh wenn Ultragram einen schönen Editor hatte, usw.

War Whalecalf doch so geil und hatte richtiges C++ auf Lager (inkl. Templates, C++-Streams, schön generisch alles, usw.).

[Sone]

Und wieder Blödsinn.
Da wird std und ein anderer Namespace mitten im Header geöffnet...

[otze]

wie wärs einfach, wenn du die Grammatik umformulierst, sodass sie LL ist? das ist nicht so schwer.

[Sone]

otze schrieb:

wie wärs einfach, wenn du die Grammatik umformulierst, sodass sie LL ist? das ist nicht so schwer.

Na ich weiß nicht, ich will lieber noch einige Dutzend Stunden mit WhaleCalf verbringen

Ich versuch mich mal mit Umformulierung. Mal sehen, was bei rauskommt.

[otze]

Der Trick ist, dass du das so mformulieren kannst, dass du erst etwas liest, was keine Aussage ist und erst dann ein "and" oder "or" optional folgt.

[Swordfish]

Sone schrieb:

[...] ich will lieber noch einige Dutzend Stunden mit WhaleCalf verbringen

... dann hast wenigstens keine Zeit im Forum zu nerven

[Sone]

otze schrieb:

Der Trick ist, dass du das so mformulieren kannst, dass du erst etwas liest, was keine Aussage ist und erst dann ein "and" oder "or" optional folgt.

Und die Klammern und NOT. Also praktisch ein Baum:

NOT (T AND F)

Wird zu

NOT     //UND SCHLIEßLICH DAS
     /
BRACED_EXPR  //DANN DAS
   / 
 AND         // DANN DAS
 / \
T   F        //ZUERST LESEN (Oder Variable >> !Index)

Oder geh ich wieder in die falsche Richtung?

[otze]

das einzige was du verhindern musst, ist dass "Aussage" linksrekursiv ist (das heißt, der Parser darf nicht ohne irgendetwas zu lesen die Ableitung Aussage->Aussage->Aussage->Aussage anwenden können. Schreib die Regeln einfahc so um, dass immer mindestens 1 Zeichen gelesen wird.

[Sone]

Bevor ich das jetzt angehe: Ist danach die Syntax die selbe?

[knivil]

Also ich hatte nie Probleme mit flex und bison .

[otze]

Ich schaue mir gerade deinen Code an:

ich würde ja die Variablen als Kleinbuchstaben lassen. Das macht die Sache eindeutig zu parsen (in LL(1))

Alternative Formulierung für Aussage:

( !() ist 0 oder 1 mal)

Aussage := ("T" | "F" | "(" Aussage ")" | "NOT" Aussage | Variable [Index])
           !( "AND" Aussage | "OR" Aussage )

[Sone]

otze schrieb:

Aussage := ("T" | "F" | "(" Aussage ")" | "NOT" Aussage | Variable [Index])
           !( "AND" Aussage | "OR" Aussage )

Teste ich gleich mal.

[Sone]

Verdammt Otze...
Wieso tust du so etwas? Jetzt hab ich NIX gelernt.
Einzig und allein gibt es den Fehler, dass

asdf4

Als falsch ausgewertet wird. Aber das fix ich selber

Ich werde aber auch noch einmal eine Version mit WhaleCalf machen (die API, die das Problem mit unsigned char hatte). Die ist zwar todeshässlich, doch ist es mal eine Erfahrung wert mit todeshässlichen APIs zu arbeiten.

[Sone]

In deiner Version, Otze, kann man übrigens "NOT" nach vorne stellen, oder?

Aussage := !("NOT") ("T" | "F" | "(" Aussage ")" | Variable [Index])
           !( "AND" Aussage | "OR" Aussage )