October 2024 - Boost - lists.preview.boost.org

Boost.Decimal Seeking Endorsment
by Matt Borland 05 Oct '24

05 Oct '24

Hello, Chris Kormanyos and I are seeking endorsement for our library proposal, Decimal (https://github.com/cppalliance/decimal) What is Decimal? It is an implementation of IEEE 754 and TR 24733[3][5], along with extensions to both. We provide three IEEE 754 compliant types: decimal32, decimal64, and decimal128, as specified in both documents. Since announcing the beta in the first half of the year, we have added three similar but non-compliant types: decimal32_fast, decimal64_fast, and decimal128_fast. These types perform all operations faster than the compliant types, with identical numerical results, at the cost of extra space. We also provide implementations of the majority of the STL as it apply to numerical types. The library is header-only, has no dependencies, and only requires C++14. Why should we have this in Boost? Decimal Floating Point types were standardized in IEEE 754 in the 2008 revision, but it has not been standardized in C++. We believe this library can serve as a reference implementation. An existing alternative would be one of the authors of the IEEE 754 standard helped write libdfp[4]. This is also available in C with GCC as _Decimal32, _Decimal64, and _Decimal128 [1]. We bring these to C++ with similar or better performance. We also bring interoperability with the STL which is missing in the aforementioned libraries. Since the announcement of our beta in the spring we have improved correctness, performance, and gained users. We added the fast types after conversation with Glen Fernandes, and bit conversions for both encodings of the types [2]. I am aware of at least one US-based trading firm using this library in production so the library is out in the field making money today. Should the library be endorsed John Maddock has graciously offered to be our review manager, and are targeting a post-holiday review period in mid-January 2025. Feel free to ask any questions, and open issues prior to the review period. Matt [1] https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html [2] https://cppalliance.org/decimal/decimal.html#conversions [3] https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2849.pdf [4] https://github.com/libdfp/libdfp [5] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html

3 4

Scheduled review of SQLite library
by Mateusz Loskot 05 Oct '24

05 Oct '24

Folks, On behalf of the Review Wizards Team, formal review of proposed SQLite library has now been scheduled: - https://github.com/boostorg/website/pull/877 The review details should be soon displayed on the website - https://www.boost.org/community/review_schedule.html Best regards, Mateusz Loskot

1 0

Boost.Parser need final approval
by Zach Laine 04 Oct '24

04 Oct '24

I've *finally* gotten back around to making Boost.Parser properly ready for bringing into the next Boost release. Marshall suggested I post here to make sure that people who participated in the review have a chance to check that the notes from the review all got fixed/implemented. So, this is that email. Please have a look if you get the chance. The issue tracker for the github project is down to 8 items, all of which are nice-to-haves. All the issues raised during the review were captured in the issues list, and taken care of. Zach

3 2

Two mqtt libraries
by Robert Ramey 03 Oct '24

03 Oct '24

I've been contacted by my friend and sometime collaborator Takatoshi Kondo regarding his submission of a boost library: https://github.com/redboltz/async_mqtt. It has received two endorsements. He has asked me to be review manager and I'm inclined to accept this request as he was very helpful to me during the refinement of the boost serialization library. There is also mqtt client library that is proposed to the Boost. https://github.com/mireo/async-mqtt5 It also has endorsements and a review manager. A cursory examination of the git hub pages suggest considerable overlap between the two submissions. In general, boost has discouraged the acceptance of multiple libraries with this much overlap - and for good reason. An accepted library often becomes the canonical implementation in large parts of the C++ world. Having two high quality libraries that do almost the same thing is not where we would like to be. I would like to propose that we review both libraries simultaneously in order to try to reach a consensus as to which, if either we want to accept. I know this is a difficult task, but I think it is important that we do this. It's going to be tough to reject a well written library because a better one has been accepted. But it would be worse to reject a well written library merely because another one was submitted first. Normally I don't participate as a review manager as I'm pretty bogged down in Boost stuff as it is. But I'm willing to make an exception in this case due to the importance of this case and my strong personal ties to Takatoshi. BTW - who is the review wizard these days? I presume that he will be the one making the decision about this. Robert Ramey

10 17