C++ parsen
-
Dich abhalten liegt mir fern, es sind nur gutgemeinte Ratschlaege. Leider hast du die Analogie nicht verstanden.
Crysis -> C++ Compiler
Nicht Programmieren koennen -> keine Ahnung von Compilerbau
Beschaeftige dich mit den Grundlagen -> Fange nicht mit einem C++ Compiler an
Kiddi -> ich will, ich will, ....
-
Warum beschäftigst du dich nicht zuerst mit einer einfacheren Sprache, z.B. einer Skriptsprache? Wenn du noch keine Erfahrung mit Code parsen hast, wäre das doch ein guter Einstieg. Interessant ist es genauso, und du musst dich nicht ins Terrain der C++-Spitzfindigkeiten und Fallunterscheidungen begeben, die sogar vielen Programmierern nicht bekannt sind. Alleine schon die ganze Überladungsauflösung ist ziemlich komplex. Von Templates wollen wir gar nicht erst anfangen...
Jedenfalls wird eine Skriptsprache deine Frustration verhindern, wenn du merkst, dass dich mit dem funktionierenden C++-Parser doch etwas überschätzt hast.
Und Autovervollständigungstools für C++ funktionieren nicht immer 100% zuverlässig, gerade weil C++ im Gegensatz zu Java oder C# wahnsinnig komplex zu parsen ist. Ich halte es für sehr unrealistisch, dass du daran einfach mal so etwas ändern kannst.
-
skNiNe schrieb:
Ich hab tatsächlich keine Erfahrung im Compilerbau. Aber ohne einen Anfang zu machen kommt man sicherlich auch nicht weiter. Ein Parser für eine Sprache wie C++ ist zwar kein guter Einstieg, aber es ist das, was ich brauche bzw. machen möchte. Ich werde mich hier ab und zu mal melden und euch über den aktuellen Stand informieren. Evtl. hat ja der ein oder andere interesse daran.
da c ein subset von c++ ist würd ich erstmal damit anfangen... die erste hürde an der ich mir die zähne ausgebissen hab ist das typsystem. da würde ich mir speziell gedanken machen. die templates würd ich für den anfang rauslassen. die sollten wenn alles steht "leicht" umzusetzen sein. zeig doch mal deinen tokenizer. das schonmal ein guter anfang.
-
Ich war eben dabei mir den ISO-Standard von C anzuschauen. Ich bin mir aber nicht sicher ob es sehr viel leichter sein wird. Natürlich fallen Themen wie Operatorüberladung, Templates, Klassen usw. weg, aber dennoch müsste man den größten Teil von C++ bzw. die vielen Überschneidungen abbilden. Mein lexikalischer Scanner existiert bisher nur auf Blättern. Laut den Definitionen im C und C++ (sind da ja beide diesbezüglich recht ähnlich) wird bzw. sollte das so auch umsetzbar sein.
Edit:
Ich kann mich zum parsen einer Skriptsprache irgendwie nicht motivieren. Es soll ein Parser für etwas sein, was ich aktiv verwende. Mein Sprachspektrum liegt in C, C++, C# und Java. Dazu muss man sagen, dass ich C# nur zwangsweise lernen musste (und mich nicht überzeugt hat). Des Weiteren gibt es für C# und Java schon gute Lösungen für das Problem, welches ich lösen wollte.
-
Ich würde dir mal einen Blick auf Boost::wave empfehlen, die haben nicht nur einen Präprozessor sondern auch einen C++ Lexer, damit konnte man schon mal einen C++ Parser durchaus in angriff nehmen, aber das ist ein sehr langfristiges Projekt, gerade wenn du auch noch C++0x unterstützen willst (was sinnvoll wäre).
Ich habe selber schon parser für verschiedene Sprachen und für C++ schon Teilparser geschrieben (Funktions deklarationen z.b.).
Für die Praxis, schau dir mal boost::spirit an, da gibts auch einen minimal C Parser afaik in den Beispielen.
-
Hallo skNiNe,
gerade wenn du noch keine Erfahrung im Compilerbau hast, solltest du ein bestehendes Framework verwenden, z.B. boost::spirit.
Dafür gibt es auch schon einige C++-Parser Implementierungen (wahrscheinlich nicht komplett vollständig, aber als ersten Anfang besser als ganz bei Null zu beginnen!):
http://boost-spirit.com/repository/grammars/show_contents.php
http://www.mailund.dk/index.php/2008/10/03/newick-c-parser-in-boostspirit/Viele Beispiele (dazu auch ein paar für den C++-Parser) gibt es unter http://boost-spirit.com/repository/applications/show_contents.php
Und hier ein Kurzeinstieg zu Parser mit boost::spirit: http://www.highscore.de/cpp/boost/parser.html
Außerdem habe ich noch einen Parser gefunden, der intern auf boost::spirit aufsetzt: http://www.sweetsoftware.co.nz/parser_overview.php
Hier übrigens eine ähnliche Anfrage bzgl. eigenen C++-Parser: http://www.gamedev.net/topic/349261-c-parser-for-visual-assist----suggestions/
-
@phlox81
Für welche Sprachen und aus welchen Grund hast du schon Parser geschrieben? Die Motivation anderer Leute die auch schonmal einen Parser geschrieben haben finde ich interessant :). Den Lexer an sich finde ich eigtl nicht unbedingt so schwer, das Problem liegt meiner Meinung nach in der Überprüfung der Semantik.@Th69
Danke für die Informationen :). Vorallem den Thread bei gamedev finde ich interessant. Leider wurde es ja bisher noch nicht geschafft, einen C++-Parser an Hand von boost::spirit zu entwickeln. Wie auch in gamedev schon beschrieben steht, läuft es darauf hinaus, dass man es doch selbst entwickeln muss.Edit:
Ich habe mir nun folgendes Buch gegönnt. Ich hoffe mal, dass es sein Geld wert ist.
http://www.amazon.de/Compiler-Prinzipien-Techniken-Pearson-Studium/dp/3827370973/ref=sr_1_1?ie=UTF8&qid=1295098835&sr=8-1
-
skNiNe schrieb:
@phlox81
Für welche Sprachen und aus welchen Grund hast du schon Parser geschrieben? Die Motivation anderer Leute die auch schonmal einen Parser geschrieben haben finde ich interessant :). Den Lexer an sich finde ich eigtl nicht unbedingt so schwer, das Problem liegt meiner Meinung nach in der Überprüfung der Semantik.Das ist immer die Frage was man machen will, ich habe mich eigentlich immer darauf beschränkt, nur Code zu generieren, und bedingt auch zu parsen (statt 10 Editboxen eine).
Schwierig wirds natürlich wenn man auch den eigentlichen Logikcode parsen will, ansonsten kann man relativ einfach eine Regel bauen die den inhalt zwischen zwei {} in einen String schreibt.Ich habe 2 Parser für TTCN3 geschrieben, unter anderem dort auch die Aufrufe später überprüft. Und Parser für diverse andere Dinge.
-
wieviele jahre bist du denn bereit dafür zeit zu investieren? das ist fast ne lebensaufgabe
-
skNiNe schrieb:
Leider wurde es ja bisher noch nicht geschafft, einen C++-Parser an Hand von boost::spirit zu entwickeln. Wie auch in gamedev schon beschrieben steht, läuft es darauf hinaus, dass man es doch selbst entwickeln muss.
Es ist nicht so, dass es ganz von Hand einfacher wäre als mit Boost.Spirit. Aber vielleicht musst du zu einem mächtigeren Lexer-/Parserframework (z.B. Flex/Bison-Kombination) greifen.
-
Nexus schrieb:
skNiNe schrieb:
Leider wurde es ja bisher noch nicht geschafft, einen C++-Parser an Hand von boost::spirit zu entwickeln. Wie auch in gamedev schon beschrieben steht, läuft es darauf hinaus, dass man es doch selbst entwickeln muss.
Es ist nicht so, dass es ganz von Hand einfacher wäre als mit Boost.Spirit. Aber vielleicht musst du zu einem mächtigeren Lexer-/Parserframework (z.B. Flex/Bison-Kombination) greifen.
lol. Tschuldigung, aber spirit ist mächtig genug, und ich kann mir nicht vorstellen, was Flex/Bison besser als Spirit könnte.
Evtl. interessant könnte hier der Quellcode von LLVM/clang sein, die haben ja einen kompletten Kompiler neu gebaut, also müssten sie auch einen Parser haben.
Dieser ist zumindest Opensource, evtl. sogar unter einer BSD ähnlichen Lizenz (also nich GPL).
-
phlox81 schrieb:
lol. Tschuldigung, aber spirit ist mächtig genug, und ich kann mir nicht vorstellen, was Flex/Bison besser als Spirit könnte.
Ich kenne die Frameworks zu wenig, um das zu beurteilen. Jedoch hat g++ meines Wissens früher auf Bison basiert. Das muss natürlich nichts heissen (ausser dass man sich vielleicht eher an einer existierenden Implementierung orientieren kann).
Das mit dem "mächtiger" habe ich schon ein paar Male gehört, aber offenbar zu Unrecht. Danke für die Anmerkung.
-
Ich verwende in einigen Programmen als Skriptsprache AngelScript.
http://www.angelcode.com/angelscript/
Das ist auch OpenSource und benutzt als Sprache eine Mischung aus C++ und Python.
Ist OpenSource, daher vielleicht ganz interessant mal zum reinschauen.
HTH ein wenig.
rya.
-
Guten Tag,
ich bin seit gestern nach wie vor am überlegen, womit ich anfangen könnte, um mir diverses Wissen dafür anzueignen. Letztens habe ich hier schonmal einen Thread geöffnet (sogar hier im falschen Forum dafür), welcher sich um GNU make handelte. Mir ist nun in den Sinn gekommen, dass ich ein kleines make-Programm schreiben könnte, welches einfacher zu bedienen und dennoch flexibler als das traditionelle make ist. Meiner Meinung nach gibt es vorallem Probleme mit z. B. Qt. Woher will make wissen, welche Header-Dateien zunächst von moc kompiliert werden müssen. qmake finde ich auch nicht unbedingt gut, da dieser (wie viele andere Alternativen zu make) zunächst ein Makefile erstellt, in dem die ganzen Sourcen und Abhängigkeiten statisch (bedeutet: nicht automatisch ermittelt werden) eingetragen werden, welches wiederrum erstmal ausgeführt werden muss, um letztendlich eine ausführbare Datei zu erstellen.
Was haltet ihr von der Idee, ein make-Programm zu erstellen, welches auf einer (sehr) vereinfachten Syntax von C/C++ basiert, um seine eigenen Funktionen zu definieren. Des Weiteren stehen bereits sämtliche Funktionen (die u. a. auch in make vertreten sind) schon im vornherein zur Verfügung. Ein solches Makefile wird von diesem make interpretiert und ausgeführt (ohne ein traditionelles Makefile zu erstellen). Um dennoch die Kompatibilität zum alten make zu bewahren, könnte es ein Feature geben, um ein Makefile in ein traditionelles Makefile zu konvertieren (demnach wird dann auch alles statisch eingetragen (wie in qmake usw.)).
Falls diese Idee Anhang finden würde, wäre es durchaus ein sinnvolles Projekt, welches zugleich eine gute Einführung ins parsen und interpretieren gibt.
Ich wäre sehr dankbar für Meinungen zu dieser Idee.
Hier noch der Link zum Make-Thread von mir:
http://www.c-plusplus.net/forum/279038Viele Grüße
-
skNiNe schrieb:
Falls diese Idee Anhang finden würde
Kennst du schon alle Build-Systeme?
Die Sache mit dem make ist halt die, dass make so ziemlich überall installiert werden kann und oft auch ist. Wenn ich ein Projekt mit deinem SMake (ich nenn es jetzt einfach mal so) schreiben würde, müsste jeder Nutzer erst einmal das README durchlesen, dann SMake installieren, dann nachschauen wie es aufgerufen werden soll, dann die Fehlermeldungen verstehen und beheben, ... Ansonsten hätte er einfach./configure && make && sudo make installauszuführen und das kennt er schon.
-
libclang hat noch keiner vorgeschlagen... liegt sicher daran, dass c++'ler boost mit der muttermilch aufnehmen. für alle nicht verblendeten wärs evtl. nen blick wert!
@edit: 5.130 ergebnisse sind in webdimensionen ja auch fast wie die nadel im heuhaufen - gerne hab ich bei der suche geholfen
-
Ich kenne einige Build-Systeme (mehr oder weniger gut). Aber gibt es denn die oben genannte Möglichkeit bspw. in eine Header-Datei zu schauen, um zu überprüfen ob diese zunächst vom MOC kompiliert werden muss? Ich will und kann natürlich kein perfektes make erstellen. Aber man könnte ja eine große Basis an Standardfunktionalität bieten, auf welcher man eine beliebige Anzahl an eigenen Funktionen aufbauen kann.
Das von dir genannte Problem bzgl. Einarbeitung in make-Programme wäre ja im Endeffekt mit der Konvertierung in ein übliches Makefile behoben. Diesen Vorgang würde man dann zu jedem Release durchführen, sodass der Benutzer des Programms oder Bibliothek nur noch sein gewohntes Makefile hat. Nur der Entwickler müsste einmal initial sein spezifischen Makefile schreiben bzw. anwenden können.
-
So, ich melde mich mal wieder :). Ich hab mich die letzten Monate mit der Materie auseinandergesetzt (Dragonbook), mich mit verschiedenen Parsertechniken (hauptsächlich rekursiv absteigend und LALR) beschäftigt. In nächster Zeit (nach meiner FIAE Abschlussprüfung anfang Mai) werde ich wohl mal einen C-Parser angehen. Wie im Verlauf des Threads schon kenntlich gemacht wurde, geht es mir nicht nur rein ums parsen, sondern um einen Parser, der eher wie eine Code-Completion arbeitet. Änderungen im Source-Code direkt nachdem diese durchgeführten wurden entsprechend parsen und den AST aktualisieren. Nun zu meiner eigentlichen Frage. Gibt es bereits Techniken, wie man so einen, ich sag mal "Live-Parser" implementieren kann?
Viele Grüße
-
Hat niemand eine Idee?
-
Ich denke die wenigsten haben schon einmal einen Live-Parser geschrieben.
Was hindert dich daran, einen schon bestehenden anzuschauen? Mal angefangen mit man: ctags (oder vllt. Geany), dann weiter zu KDevelop oder anderen IDEs.Genau darum gibt es Open Source.
