On Thu, May 28, 2015 at 9:12 AM, Christophe Henry < christophe.j.henry@gmail.com> wrote:
Dear all,
The review of the metaparse library started last Monday. Please consider taking the time to review it and post comments or reviews on this list.
Thanks,
Christophe
[snip]
Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list.
Please always include in your review a vote as to whether the library should be accepted into Boost.
Yes.
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design?
I don't have much negative to say about the design, because the functionality is similar to mpl, which I am also familar with. I like the consistency of the interface(s). As others have noted, it would be interesting to try the newer style of TMP (dependent typing), because syntax similar to Spirit might be possible. Requiring an internal `::type` for result types also surprised me (also previously noted). The only other point is a nitpick (again, previously mentioned) - the `any` parser is surprisingly repetitive and not an alternation. - What is your evaluation of the implementation?
I looked at some of the implementation (I was curious). The parts I saw seemed well-written. Some thoughts: * Adding support for the Gcc character-literal expansion extension would be nice, because the strings macro has some intense pre-processor work. * Compiling in C++11 mode is noticeably quicker for some of the examples I tried (in clang and gcc) - due to the true variadic string implementation (no pre-processor)? ** I noticed some of the other areas used pre-processor variadics (one_of, etc.), could C++11 variadics improve compilation time here? ** Using boost::mpl::vector for sequences/repeats feels ancient, could this be moved to a mpl conformant C++11 variadic implementation too? mpl has pre-processed headers, but still have lots of symbols/code for the compiler to parse and manage for the variations. Since the documentation states that the repetition/sequence based parsers return a "implementation-defined" mpl sequence, could this data structure be swapped in c++11 mode? Unfortunately I can't find a compile-time performance comparison of mpl::vector and a similar data structure using C++11 variadics. - What is your evaluation of the documentation?
I find the documentation suitable, but I also skimmed the tutorial and went to the libray reference instead. After looking at a few examples, I started "hacking" at it. The diagrams in the documentation were also nice. - What is your evaluation of the potential usefulness of the library?
- Did you try to use the library? - With what compiler?
Yes. With gcc 4.8 and clang 3.5. I have a partially implemented a printf format string to spirit::karma expression tree conversion utility that uses metaparse. The library worked exactly as expected everytime, the difficulties were mainly in the complexities of the printf specification. - Did you have any problems?
The compile-times I experienced were not great. A decent portion may have been due to the usage of spirit, another library known to have significant compile times. The (somewhat) simple calculator example still takes ~2.5s to compile in clang 3.5 C++11 mode. This was on an older laptop, maybe I should just upgrade. Although it would be nice to see if there are ways to improve on the compilation time - otherwise people might avoid this library. The framework that Louis mentioned previously seems worthwhile. - How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
A decent amount of effort considering how much of the library I used for my printf->spirit utility. A little less on the tutorial and getting started part of the documentation. - Are you knowledgeable about the problem domain?
I'm fairly knowledgable of TMP techniques, but new to compile-time parsing. Its difficult for me to say whether a better solution exists for this specific problem. Lee