|
Boost : |
From: Scott Woods (scottw_at_[hidden])
Date: 2005-09-14 18:38:02
* What is your evaluation of the design?
Good. It has taken some powerful, established technologies (e.g. regular
expressions and parser generators) and delivered a C++ facillity that uses
some of the latest C++ techniques.
Hosting these technologies within C++ syntax has resulted in some slightly
jarring constructs (e.g. prefix "one-or-more", tag assignment) but
the set of design decisions made seem very reasonable.
There were some corners that got me curious; the following queries
are therefore more about curiosity than suggestions for change.
1. What is the benefit of providing the complete match in the
first entry of the results? e.g. "what[0]". While this is consistent
with a long tradition in RE, after some time with STL it's
presence at position zero wasnt as comfortable as I expected.
2. Why the slash syntax in dynamic regex? The resulting
requirement for a double is fairly ugly. It may be consistent with
something (Perl/ECMA/..?) but on balance is it worth it?
3. Why ">>" and not "," (comma). Did the "set" facillity
take priority or does the low precedence of comma just result in
a different ugliness (sorry, not really the word I want to use :-).
4. C++ operators and RE operators are not really comfortable
bed-fellows. While the operator overloading technique has given
something useful and concise was there no flirtation with "key words"
(i.e. in the manner of "as_xpr"). "+" could have been "one_or_more( xpr )".
Maybe the keyword version is viable as an alternate targeted at
beginners? Unjustifiably complex?
5. There didnt appear to be much specific thought given to file processing.
Is
this another "not yet implemented"? In particular elegant integration
with any async I/O facillity arising from sockets and file I/O initiatives.
6. Very interested in the future of "semantic actions". Actions and file
processing probably go together?
* What is your evaluation of the implementation?
Cannot say. Not used.
* What is your evaluation of the documentation?
Good. I liked the balance of technical terminology combined with
some informality.
Appeared to be some minor problems such as initially not knowing what
"_w" and "_d" meant. Was this my failing or was there a missing
definition. Was the later use of "+alpha" and others inconsistent?
* What is your evaluation of the potential usefulness of the library?
Huge. Some of that answer refers to the usefulness of RE but xpressive
is obviously more. There has been some discussion about overlap with
regex. It would be nice to clarify that.
The uptake of RE within the development community (at least, the one
where I live) is almost embarrassingly low. I have seen many circumstances
that cried out for the power and rigor of RE that instead got limited,
buggy hand-written solutions. The ease-of-use (installation, build and
coding) of xpressive might help?
* Did you try to use the library? With what compiler? Did you have
any problems?
No.
* How much effort did you put into your evaluation? A glance? A
quick reading? In-depth study?
An in-depth study with a glaring omission; the library was not
used. Lack of time, old compiler, employer resistance to boost.
* Are you knowledgeable about the problem domain?
Yes.
* Do you think the library should be accepted as a Boost library? Be
sure to say this explicitly so that your other comments don't obscure your
overall opinion.
Yes.
Cheers.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk