Subject: Re: [boost] [metaparse] Review period starts May 25th and ends June 7th - ongoing
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-06-03 17:42:23
Louis Dionne <ldionne.2 <at> gmail.com> writes:
> I am currently going through Metaparse's tutorial, and here are some questions
> and comments I have so far. I will be posting more questions by replying to
> this message if some come up as I progress through the tutorial. I will
> provide a proper review of the library when I'm done.
Abel, I have a few more comments and questions.
3. First, a non-technical point about the tutorial.
I will reiterate my position about the format of the tutorial being slightly
inadequate. I was around the end of the tutorial and I wanted to copy/paste
everything we had so far so I could play with it. To do this, I had to
copy/paste bits of solutions going up to the beginning of the tutorial.
All in all, it took me about 15 minutes to put the right bits together and
to get the final example compiling in a single file on my machine. The
format of the tutorial is 100% incremental, but my reality when reading a
tutorial is that I go to it and then come back, and I expect the milestones
to be larger-grained than what Metaparse provides.
I think a solution that would address 90% of my complaint would be to
provide "what we got so far" code blocks on important milestones. That
way, one could simply copy/paste the whole code block and get started
right away. Other than this, I like the way you introduce concepts and
I never felt lost reading the tutorial. Good job on the redaction.
4. I would like to see metaparse provide a master header including everything
else (like `boost/metaparse.hpp`). I don't mean that such a header is
terribly useful when actually coding, because you'll never want to pull
the whole thing in production code. However, it makes the process of
learning and hacking stuff around so much easier, cause you just have to
#include the whole thing and get started. Since being easily teachable and
hackable is an important feature of a library, I think a master header
would be valuable. Also, it is a trivial change.
5. I would like to see charts showing compilation times in relation to the
complexity of the parser as well as the length of the input. For example,
I would like to see how the simple calculator example behaves at
compile-time for different input sizes, and how the one with error
handling does, and so on. However, since I know it's a total pain in the
ass to set this up oneself (I did it for MPL11 and Hana), I could set it
up for you, show you how to write the benchmarks with my framework and
then you would do the rest of the work yourself. To make this more
concrete, here's what I have been able to generate in about 10 minutes
of work. It is a benchmark of the final parser we end up with (with error
handling and all) for different sizes of input:
I must agree this is not conclusive at all, but like I said I hacked it
out in 10 minutes and I don't know the internals of the library.
6. While doing the above benchmarks, Metaparse threw up with strings of about
37 characters long. I believe this limitation has something to do with how
the MPLLIBS_STRING macro is implemented. However, there are other
alternatives to this macro when C++11 is available. See for example
how I do it in Hana here: https://goo.gl/9dxVtx
There's also a GNU extension supported by both Clang and GCC which allows
compile-time strings to be defined using a user-defined literal. You can
also see how Hana uses it through the above link. I think it would be a
very, very valuable addition to the library to support longer strings via
those techniques when the compiler supports it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk