Re: Design/structure X3 parser more like Qi parser
Seth <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
On 07-12-16 17:30, Sandro Pirkwieser wrote: > In X3 the encapsulation can only be "approximated", and it seems the more achieving this goal decreases the possibility of reusage and integration into another parser. I don't look at it that way. In my mind, Qi had a few red-tape classes required because of language limitations. This, incidentally, contributed to very long compile times, because of all the template machinery that went under the hood. In X3, the policy clearly changed: it favours using C++ language features as much as possible. This simultaneously cuts compile times and (more importantly?) _learning curve_. Instead of having to work with the idiosyncrasies of a handful special purpose boost libraries you get 80% of the way with /just regular C++/. Key example is, of course, semantic actions, which are "simple lambdas". Yes, this comes at the cost of some syntactic sugar that Qi had, but it makes the library less intrusive and more easilly extended. > x3::any_parser and deriving from x3::parser_base? They are not covered by the official docs, as their usage is probably not intended(?) Both are simply not documented then (not checked). They are very much intended to be used. > As an upside the compile time is reduced to one third, which is quite impressive, but as a downside the runtime is up to twice as much. If you can share this in a minimal slefcontained example then ew might review it ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi