kennt jemand einen guten Scanner- und Parser-Generator für C++? Es sollte frei verfügbar sein und der erzeugte Code sollte möglichst unter Windows mit dem Visual Studio laufen. Der von Flex/Bison erzeugte Code enthält bei mir etliche Fehler und ich muss da viel per Hand dran ändern. Außerdem sieht mir der Code extrem unleserlich aus. An ANTLR stört mich vor allem, dass es ein LL(k) Parsergenerator ist. Ich hätte eigentlich lieber einen für LALR-Grammatiken.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Boost Spirit.

Spirit ergibt doch immer einen Top-Down-Parser?

blah2: flex und bison können auch C++-Code generieren. Im Notfall kann man auch ein C-Modul mit einlinken.

Artchi schrieb:

Boost Spirit.

Spirit ergibt doch immer einen Top-Down-Parser?

blah2: flex und bison können auch C++-Code generieren. Im Notfall kann man auch ein C-Modul mit einlinken.

Flex/Bison würde ich nicht verwenden. In C++ kann fieserweise an fast jeder Stelle eine Makro aufgerufen werden. Das macht die Sache schon schwerer.
Auch die GCC Leute sind iirc von einer automatisch generierten (und auch customizeden) Parserengine bei Version 4 auf einen komplett handgeschriebenen Parser umgestiegen. Das hat nicht nur den Vorteil der größeren Flexibilität (Makros handlen z.B.), kann aber auch schneller sein.

Meinungen zu der Makroproblematik?

Meinungen zu der Makroproblematik?

Makros werden doch eh vorher weggedingst? Also vom Präprozessor-Pass. Bzw. gleichzeitig und mit Pipes...

Flex/Bison würde ich nicht verwenden. In C++ kann fieserweise an fast jeder Stelle eine Makro aufgerufen werden. Das macht die Sache schon schwerer.

In C auch. Erklär mal bitte, warum das hier ein Problem sein soll, ich verstehs ehrlich gesagt nicht.

Auch die GCC Leute sind iirc von einer automatisch generierten (und auch customizeden) Parserengine bei Version 4 auf einen komplett handgeschriebenen Parser umgestiegen. Das hat nicht nur den Vorteil der größeren Flexibilität (Makros handlen z.B.), kann aber auch schneller sein.

gcc hat ja auch sehr spezielle Anforderungen, z.B. eine extrem perverse Sprache, die sich nicht ohne einige pragmatische Tricks mit den aus der Theorie bekannten Methoden erschlagen läßt.

Mh, stimmt, ein zusätzlicher Compilerdurchlauf könnte das Problem beheben. Was meinst du mit den Pipes?

Ich denke er meint damit, dass man zuerst jedes token dass der parser anfordert überprüft ob es ein makro ist, und bei bedarf das makro auflöst. dann bekommt der compiler ohne einen zweiten pass direkt den "fertigen" code.