|
Boost : |
Subject: Re: [boost] [metaparse] review
From: Abel Sinkovics (abel_at_[hidden])
Date: 2015-06-03 16:55:06
Hi Andrzej,
On 2015-06-03 22:32, Andrzej Krzemienski wrote:
> 2015-06-03 21:44 GMT+02:00 Abel Sinkovics <abel_at_[hidden]>:
>
> I am not quite sure either. Sorry, if I am being imprecise. For instance, I
> am rather impatient (and I suspect I am not the only one), and expect that
> I will learn from the documentation in less than three minutes, what is its
> scope, what I will and will not able to do with it, and how using it will
> look like. In the metaparse doc, I was not able to do that, I was forced to
> read the tutorial, whose pace is too slow for me. I got impatient and
> distracted.
>
> My remark is not to the amount of information, but to how it is ordered.
> For instance, when you look at the documentation of Optional (
> http://www.boost.org/doc/libs/1_58_0/libs/optional/doc/html/index.html), in
> the first page you get a short example of how it is used and why you want
> to use it. The potential user can immediately make a decision whether she
> wants this library or not.
>
> I hope I am making sense. I cannot describe it any better. Perhaps it is
> just personal preference.
If I understand you correctly, some example from which one can "easily"
tell what the library is about would make sense in the documentation
(probably on the first page).
For optional it is easy, as its scope is small and the concept is well
known. For a compile-time parser generator library it is more difficult
to come up with such an example, but I'll try my best.
> BTW, nor I recall one thing, I failed to bring up earlier. There parser for
> detecting repeated elements is called "any". This name seams inadequate.
> Perhaps "any_number_of_times" or "repeated" would indicate the intent more
> clearly?
I find "any_number_of_times" very long. "any_of" is shorter and things
like "any_of<int_>" seem to be understandable (and are similar to the
way "one_of" is named).
Regards,
Ábel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk