H
So, ich lass erstmal die Pfoten von Spirit. Dazu drei Begründungen, die jeder, der das zu benutzen gedenkt, vorher einmal überdenken sollte:
So genial der modulare Aufbau auch sein mag, das Verhalten des zusammensetzens einzelner Objekte und ihre Rückgabewerte, sind meiner Meinung nach nicht ausreichend mit Beispielen dokumentiert. An sich ist der Aufbau der Dokumentation super, gerade im Einführungsbereich, viele Librarydokus können sich da scheibenweise was von abschneiden, aber je weiter es in die Materie geht, wird es dünner. Ich habe mir wirklich Mühe gemacht, aber z. B. noch nicht herausgefunden, warum eine Rule, die aus zwei Rules, die jeweils einen Vektor zurückgeben, nicht in ein pair<vector, vector> passen mag, wohl aber in eine mit BOOST_FUSION_ADAPT_STRUCT gebaute struct. Wenn man Phoenix, Lambda und Fusion King ist, hat man es sicher etwas leichter.
Das Kompilieren einer simplen Grammar dauert auf meinem High-End Rechner in Visual-Studio 2010 knapp eine halbe Minute. Schnell mal eine Zeile abändern und experimientieren ist nicht.
Dadurch, dass Spirit mit komplex verschachtelten Templates funktioniert, sind Compiler-Errors idR höchst kryptisch. Mit der Zeit kriegt man zwar ein Gefühl dafür, worans liegen kann, da sich die Meldungen aber nie auf Stellen im eigenen Code beziehen, sollte man vor dem Kompilieren nicht zuviele Änderungen machen. Letzteres dauert dann wieder 30 sec.
Debugging in Runtime muss man gewissermaßen mit ein paar Hilfsfunktionen für jede Regel selbst implementieren.
Wenn man etwas simples wie im Beispiel oben machen will, geht das mit Regex einfach fixer.
Ich hab trotzdem nach wie vor Bock auf Spirit, denn ich kann mir vorstellen, dass es ab einem gewissen Level an Erfahrung darin einfach wahnsinnig Spaß macht. Man sollte die Library und Phoenix aber mehr oder weniger auswendig können.
