|
Boost : |
Subject: [boost] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-04-20 14:14:13
Dear Boost,
A second round of community review begins for proposed
Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as
it's my fault for starting another peer review straight after
Boost.Align ends, however I was busy as Google Summer of Code admin
until today, and I will be preparing to talk at C++ Now straight
after this review ends. I hope that this doesn't affect the
community's willingness to contribute to the review.
Reminder of the report from the last TypeIndex v2.1 review:
https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0
Reminder of the original peer review announcement:
http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li
brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html
Source code: https://github.com/apolukhin/type_index/zipball/master
Github: https://github.com/apolukhin/type_index
Documentation: http://apolukhin.github.com/type_index/index.html
Changes in TypeIndex v3.0 since v2.1 (from my own review of it):
1. Documentation is hugely improved over v2.1, lots of side by side
examples illustrating the differences and similarities.
2. You can now create your own custom type indices using an
extensible framework.
3. boost::typeind::type_info now exports raw_name() and pretty_name()
to maximise MSVC-GCC compatibility, and to solve point 1 but not
point 2 in the v2.1 report.
4. The undefined behaviour trick used in v2.1 has been replaced with
a cast via the placeholder type boost::typeind::detail::ctti_data
which can be viewed in
https://github.com/apolukhin/type_index/blob/master/include/boost/type
_index/ctti_type_index.hpp. There is an explanation in the comments
there about this technique's compatibility with the C++ standard.
5. TypeIndex now defines everything in the boost::typeind namespace
instead of the boost namespace.
So:
1. What is your evaluation of the design?
2. What is your evaluation of the implementation?
3. What is your evaluation of the documentation?
4. What is your evaluation of the potential usefulness of the
library?
5. Did you try to use the library? With what compiler? Did you have
any problems?
6. How much effort did you put into your evaluation? A glance? A
quick reading? In-depth study?
7. Are you knowledgeable about the problem domain?
And finally, every review should answer this question:
8. 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.
Thanks,
Niall
-- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk