Warum geht das bei C++ nicht?

Kann man C++ mit einem LL(k)-Parser parsen?

C++ hat aber eine kontextfreie Grammatik?

den Link findet man uebrigens in 20s von deiner Seite aus ...

http://www.nobugs.org/developer/parsingcpp/ schrieb:

A few web searches turned up an YACC-compatible LALR grammar written Jim Roskind which parses an early version of C++ (before namespaces, exceptions, templates and the bool type were added into the language). This is accompanied by a very useful discussion of the ambiguities in the C++ language, and how various conflicts in the grammar were resolved. This is just a grammar, and so doesn't build a full symbol table. It also uses a 'hack' to help the parsing -- enough semantic information is fed back to the lexer to allow the lexer to classify identifiers as either plain identifiers or typedef names, which makes parsing a bit easier at the expense of tangling the implementation a bit.

The next thing I came across was a C++ grammar for ANTLR. ANTLR is a parser generator which works on predicated LL(k) grammars. A predicated LL(k) grammar differs from an LL(1) grammar in the following respects. Firstly, it uses k symbols of lookahead. Theoretically, this would make the parser much slower, but in practise it doesn't slow things down much. Secondly, the choice of which production to use can be based on the next k terminals, and additionally, some syntactic predicate and/or a semantic predicate (such as 'lookup the identifier in the symbol table and if it's a type then use this production').

Ich tippe auf zwei Faktoren die dazu führen, dass man C++ nicht mit so einem Parser lesen kann/sollte:

1. Pre-Prozessor und bedingte Makros - fiese Sache für Parsersachen
2. namespaces & using namespace - macht es schwer bis Unmöglich den korrekten Typ eines Objektes nur aus dem AST heraus zu lesen.

Macht Sinn?

Ich tippe auf zwei Faktoren die dazu führen, dass man C++ nicht mit so einem Parser lesen kann/sollte:

1. Pre-Prozessor und bedingte Makros - fiese Sache für Parsersachen

Das glaube ich eher nicht. Denn: Der Präprozessor ist ein einfacher Textersetzer, der eimal über die Datei läuft. Danach sind die ganzen #-Sachen weg. Die Datei die dabei rauskommt kriegt der Compiler gefüttert. Von Makros ist da also schon nix mehr zu sehen.

Da sonst keiner Rät:

Ich finde es sinnlos. Hat LL/LR etwa in 8 Minuten meinen Link und alle dort verlinkten Artikel durchgelesen und entschieden, dass es dort nichts interessantes zu sehen gibt? Und dann kommt keine fundiertere Nachfrage als "ich finde die Antworten nicht"? Sehr motivierend

1. Pre-Prozessor und bedingte Makros - fiese Sache für Parsersachen

Nicht wirklich. Preprocessor-Direktiven sind nur schwierig für Utilities, die den Quelltext erhalten müssen, wie Dokumentationstools, Beautifier, Refactoring-Tools usw. Der Preprocessor selbst ist relativ leicht zu implementieren, danach arbeitet der Compiler auf einem "sauberen" Quelltext.

2. namespaces & using namespace - macht es schwer bis Unmöglich den korrekten Typ eines Objektes nur aus dem AST heraus zu lesen.

Ich sehe da keine zusätzliche Schwierigkeit gegenüber z.B. record-Membern in anderen Sprachen. Den Typ brauchst du bei der Syntaxanalyse aber auch gar nicht. Jedenfalls normalerweise, in C schon

ich habe mir die Artikel nicht durchgelesen, weiß also nicht ob meine auf die Semantik bezogenen Kommentare überhaupt Sinn machen:

Makros:
Wie willst du Makros a la "#ifdef LINUX" oder "#ifndef GCC" handeln?
Wenn dann noch so Schweineieren wie "#ifdef 5+4*2 > 0" auftauchen wirds schwer..

Namespaces sind mit using sehr mies (siehe nächster Code). Wenn man rausfinden möchte welche Funktion man beispielsweis aufruft, muss man immer wissen, in welchem Namespace man sich gerade befindet. Aber was sind record-Member ,Bashar?

ich habe mir die Artikel nicht durchgelesen, weiß also nicht ob meine auf die Semantik bezogenen Kommentare überhaupt Sinn machen:

Makros:
Wie willst du Makros a la "#ifdef LINUX" oder "#ifndef GCC" handeln?
Wenn dann noch so Schweineieren wie "#ifdef 5+4*2 > 0" auftauchen wirds schwer..

Nein, das sieht der Compiler alles nicht mehr. Das macht der Präprozessor vorher schon alles platt.

Makros:
Wie willst du Makros a la "#ifdef LINUX" oder "#ifndef GCC" handeln?
Wenn dann noch so Schweineieren wie "#ifdef 5+4*2 > 0" auftauchen wirds schwer..

Ich seh da ueberhaupt kein Problem. Das zu parsen ist einfach, und in einer map kann ich auch ganz einfach nachschauen, ob da ein Symbol vorkommt. Und das Auswerten arithmetischer und sonstiger Ausdrücke sollte IMHO einen Compilerentwickler nicht vor unüberwindliche Hindernisse stellen.

Namespaces sind mit using sehr mies (siehe nächster Code). Wenn man rausfinden möchte welche Funktion man beispielsweis aufruft, muss man immer wissen, in welchem Namespace man sich gerade befindet.

Ja das sollte man wissen. Aber was hat das mit C zu tun, du musst auch in Pascal wissen, in welcher Prozedur du gerade bist.

Aber was sind record-Member ,Bashar?

struct-Elemente, nur (ansatzweise hoffentlich) programmiersprachenunabhaengig gesprochen.