pon., 15 sty 2024 o 11:31 Christopher Kormanyos via Boost < boost@lists.boost.org> napisał(a):
Dear all,
The review of Boost.Charconv by Matt Borland runs Monday, January 15th through January 25th, 2024.
Code: https://github.com/cppalliance/charconvDocs: https://master.charconv.cpp.al/Review Schedule: https://www.boost.org/community/review_schedule.html
Thank you for considering this review.
Please optionally provide feedback on the followinggeneral topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain?
Christopher KormanyosBoost.Charconv Review Manager
Not a review, but some observations about docs. It looks like `limits` is something that every responsible usage of to_chars should use. It should be introduced in all the initial examples of to_chars. https://master.charconv.cpp.al/#limits_examples -- these examples do not compile (missing closing square bracket). Are there some requirements on how the numbers are converted to characters? How is it that 1.03 is rendered as "1.03" when there are surely longer sequences of characters that are closer to the numeric value really stored in the object of type `double`. The docs do not make it clear if a trailing zero is appended to the produced output. `std::to_chars` does not append the nul-terminator. If boost::to_chars does the same, the examples in the docs that use strcmp cannot be right. (You are not zeroing the buffer initially). Generally I feel Boost needs a library that does this (to_chars for C++11). I just do not feel qualified to review the implementation. However, using `malloc` in the corner cases ( https://github.com/cppalliance/charconv/blob/master/include/boost/charconv/d...) and using word "non-allocating" in the docs doesn't seem right. You could say in the docs what corner cases these are. Maybe it makes sense to allocate in those cases. But you cannot say they are "non-allocating". Regards, &rzej;