January 2024 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

Boost Governance?
by René Ferdinand Rivera Morell 10 Aug '24

10 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 10

Paul Bristow
by John Maddock 09 Aug '24

09 Aug '24

I've just heard that Paul Bristow who helped so much with the development of Boost.Math and indeed many other libraries, passed away peacefully last week. RIP Paul. Much missed. John.

7 7

boost::any_cast gives build errors with VS2022, boost v1.82 and C++17
by Bhuyan, Jyotideep 01 Jul '24

01 Jul '24

Hi, I was using VS2019, boost v1.78, and C++14 version and the below code was working well. Same code gives build error with VS2022, boost v1.82, and C++17 due to "o << *boost::any_cast<T>(&a); " Instruction. I wanted to know why it behaves differently. Code : class any_out { struct streamer { virtual void print(std::ostream& o, const boost::any& a) = 0; virtual streamer* clone() = 0; virtual ~streamer() {} }; public: any_out() : m_streamer(nullptr) { } ~any_out() { delete m_streamer; } template <typename T> any_out(const T& value) : m_streamer(new streamer_imp<T>), m_object(value) { } any_out(const any_out& a) : m_streamer(a.m_streamer ? a.m_streamer->clone() : nullptr), m_object(a.m_object) { } template <typename T> any_out& operator=(const T& r) { any_out(r).swap(*this); return *this; } any_out& operator=(const any_out& r) { any_out(r).swap(*this); return *this; } any_out& swap(any_out& r) noexcept { std::swap(m_streamer, r.m_streamer); std::swap(m_object, r.m_object); return *this; } friend std::ostream& operator<<(std::ostream& o, const any_out& a) { if(a.m_streamer) { a.m_streamer->print(o, a.m_object); } return o; } boost::any& get() { return m_object; } const boost::any get()const { return m_object; } bool empty() const { return m_object.empty(); } private: template <typename T> struct streamer_imp : public streamer { virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << *boost::any_cast<T>(&a); } } } virtual streamer* clone() { return new streamer_imp<T>(); } }; // Members streamer* m_streamer; boost::any m_object; }; I have migrated to VS2022, boost v1.82, and C++17, and due to a build error, I have changed the code below. virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << boost::any_cast<T*>(a); } } } any_out anyTest; anyTest = 100; std::string actualStr; actualStr = make_string() << anyTest; actualStr prints nullptr (0000000) instated of value 100 for VS2022, boost v1.82 and C++17 Best Regards, Jyotideep (JD) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

4 7

GSOC '24 at Boost
by David Bellot 05 May '24

05 May '24

Hi all, Another year, another GSOC's coming! As you all know now, Inbal is in charge of managing our GSOC program at Boost. Over the past years, I had the pleasure to work with many of you and we had the chance to have many great students and mentors. This year, however, it seems we don't have enough mentors yet. I know it's just the beginning of the year, but I would like to encourage you to join this program as a mentor, and help students to participate in Boost and become great C++ developers. It's a very rewarding journey I took myself years ago and you will learn so much, both on the technical and human side. If you want to become a mentor, just add your name to this shared spreadsheet: https://docs.google.com/spreadsheets/d/1_eUWRsXnhi_JwKZbHZsGQf3WNUESsAPE4lV… Cheers, David

4 3

critical bugs in charconv
by g.peterhoff＠t-online.de 05 Feb '24

05 Feb '24

Hello Matt, Sorry for submitting a bug report this way. (Having problems with my GitHub account at the moment). Code: Attachment (gcc 13.2 -std=gnu++23 -O3 -Wall -fanalyzer) Errors (normal) - Missing sign - Hex exponent is wrong - Hex is completely wrong - Accuracy is not correct - Error code deviates from the standard ... The backup functions via (quadmath)snprintf do not work. Errors (critical) - If the buffer is too small (e.g. set the array size to 3) there are a lot of buffer overflows. Especially with value ±nan/±inf. The functions should therefore always be structured in the same way: Auxiliary function inline constexpr bool is_valid_range(const char*const first, const char*const last) noexcept { return (first!=nullptr && last!=nullptr) ? first < last : false; } Pseudocode to_chars(...) // FP { to_chars_result result{last, std::errc::value_too_large}; if (is_valid_range(first, last)) [[likely]] { const size_t size = size_t(last - first); if (inf or nan) [[unlikely]] { if (size is large enough) { copy the string values into the range result = ...; Here you could also use #define to specify whether the string values are compatible with the standard or not. "±inf", "±nan" or https://develop.charconv.cpp.al/#to_chars_usage_notes_for_to_chars_for_floa… } } else { convert, detail::implemantation(first, size, ...) result = ...; } } return result; } to_chars(...) // INT { to_chars_result result{last, std::errc::value_too_large}; if (is_valid_range(first, last)) [[likely]] { const size_t size = size_t(last - first); convert, detail::implemantation(first, size, ...) result = ...; } return result; } This can be achieved with templates and typetraits: FP boost::is_floating_point still does not contain any C++23 types. template <typename Type> BOOST_NOINLINE typename std::enable_if<std::is_floating_point<Type>::value, to_chars_result>::type to_chars(char*const first, char*const last, const Type value, const chars_format format, const int precision) noexcept; template <type name Type> BOOST_NOINLINE typename std::enable_if<std::is_floating_point<Type>::value, to_chars_result>::type to_chars(char*const first, char*const last, const Type value, const chars_format format) noexcept; INT (boost)is_integer is unfortunately still missing. template <type name Type> BOOST_NOINLINE typename std::enable_if<boost::is_integer<Type>::value, to_chars_result>::type to_chars(char*const first, char*const last, const Type value, const int base = 10) noexcept; regards Gero

4 5

[Scope] Peer review conclusion
by Дмитрий Архипов 05 Feb '24

05 Feb '24

Dear Boost community, the formal review of Boost.Scope has taken place between 26th of November and 5th of December of the previous year. I have received 5 reviews in total, including 4 here on the mailing list and 1 on Reddit. Two of the reviews recommended unconditional, and 3 conditional acceptance. The reviews came from: - Klemens Morgenstern, - Janko Dedic, - Julien Blanc, - David Sankel, - /u/jonesmz on Reddit. Also, several people have given insightful comments but did not provide a review. I would like to thank all of the people who took their time to write reviews or participate in the discussions. Your effort was very important and valuable. The outcome of the review is that Boost.Scope is ACCEPTED with several minor CONDITIONS. 1. noexcept specification on destructors of scope guards should be properly documented. Andrey has already commented that the technical hurdle that prevented it was eliminated. 2. There should be a good motivating example for scope_success. There was a lot of comments regarding scope_success and its seeming uselessness. Without a good example I see the same pattern occurring with future users. 3. The examples should better describe what they are trying to achieve. Several comments about examples suggested incorrect changes, which signals that readers failed to understand them. After a lot of consideration I decided against requesting the author to remove unique_resource and related functionality from the library. While several reviewers wanted a more "concise" library, all noted that the component is useful. One last thing I wanted to point out is that all reviewers and most commenters were adamant that compatibility with the Technical Specification on which this library was initially based should not be a goal. In fact, Andrzej Krzemienski even noted that such compatibility has prevented him from adequately evaluating the library on its own merit. In my opinion this should be a sign to all of us that people prefer better APIs over standard APIs. I recommend Andrey to re-evaluate those parts of the library's APIs that he copied from the TS and potentially pick better names for member functions. Thanks to Andrey for submitting this library to Boost. And thanks again to the reviewers and everyone who provided feedback, who ultimately made this review possible.

3 5

Using ASIO to wait on a foreign socket being readable, with a timeout
by Dominique Devienne 31 Jan '24

31 Jan '24

Hi, I'm trying to use ASIO to wait until a socket is ready to read, or timeout. This is a blocking wait. But the socket is not "owned" by ASIO, but is from the libpq PostgreSQL connection. So ASIO should NOT consume any of the input on the socket, just notify me when that socket is "read-ready". I've cobbled together the following test code: ``` const int socket2 = PQsocket(conn2.handle()); BOOST_CHECK(socket2 > 0); int timr_err_code = 0; int sock_err_code = 0; bool timr_aborted = false; bool sock_aborted = false; std::string timr_err_msg; std::string sock_err_msg; bool timed_out = true; auto c1 = "C# 1"sv; conn2.listen(c1); conn1->notify(c1, "wake up!"sv); { boost::asio::io_context io_ctx; boost::asio::ip::tcp::socket io_sock(io_ctx); io_sock.assign(boost::asio::ip::tcp::v4(), socket2); boost::asio::steady_timer io_timer(io_ctx); io_timer.expires_from_now(std::chrono::milliseconds(100)); io_sock.async_wait( io_sock.wait_read, [&](const boost::system::error_code& errc) { if (errc) { sock_err_code = errc.value(); sock_err_msg = errc.message(); sock_aborted = (errc == boost::asio::error::operation_aborted); } timed_out = false; //io_timer.cancel(); io_ctx.stop(); } ); io_timer.async_wait( [&](const boost::system::error_code& errc) { if (errc) { timr_err_code = errc.value(); timr_err_msg = errc.message(); timr_aborted = (errc == boost::asio::error::operation_aborted); } io_sock.cancel(); io_ctx.stop(); } ); io_ctx.run(); // blocks until either async op above runs } // there's a notif to read, so io_sock.async_wait should have completed BOOST_CHECK_EQUAL(timr_err_code, 0); BOOST_CHECK_EQUAL(sock_err_code, 0); BOOST_CHECK_EQUAL(timr_err_msg, ""); BOOST_CHECK_EQUAL(sock_err_msg, ""); BOOST_CHECK_EQUAL(timr_aborted, false); BOOST_CHECK_EQUAL(sock_aborted, false); BOOST_CHECK_EQUAL(timed_out, false); auto notif = conn2.notification(); BOOST_REQUIRE(notif); BOOST_CHECK_EQUAL(notif.backend_pid(), pid1); BOOST_CHECK_EQUAL(notif.channel(), c1); BOOST_CHECK_EQUAL(notif.payload(), "wake up!"sv); ``` The io_sock.async_wait(io_sock.wait_read, ...) succeeds, the IO loop stops as expected, but when I try to PQconsumeInput() from the LIBPQ connection next (as shown in the code below) ``` Notification Connection::notification() { auto [lock, hndl] = ensure_handle(); if (1 != PQconsumeInput(hndl)) { throw std::runtime_error(error_msg()); // <<<<<< THROWS } PGnotify_uptr notif{ PQnotifies(hndl) }; return Notification(std::move(notif)); // may be null } ``` that calls fail with this error message: fatal error: in "NotificationTests/test_across_backends": class std::runtime_error: could not receive data from server: Socket operation on non-socket (0x00002736/10038) LIBPQ didn't like what ASIO somehow did on the socket descriptor. The LIBPQ doc says to select() the descriptor, but I thought ASIO would be cleaner, more C++, and perhaps more cross-platform. Can somehow help, telling me if I'm using ASIO incorrectly here? Thanks, --DD

3 2

Boost.Charconv review runs January 15th - 25th, 2024
by Christopher Kormanyos 31 Jan '24

31 Jan '24

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

15 76

[charconv] is std::from_chars practical?
by Andrzej Krzemienski 26 Jan '24

26 Jan '24

Hi Everyone, This is about https://github.com/cppalliance/charconv/issues/110, again. Now I understand Peter's point better. std::from_chars is impractical, or one would say "broken", at least for the case of ERANGE. Actually applying a patch in https://cplusplus.github.io/LWG/lwg-active.html#3081 will not make the tool good, it will just make it broken in another way. In that case, maybe the goal of providing literally a *drop-in replacement* for std::from_chars is not a good one? Maybe this is the case similar to variant2, where the community would benefit more from the library motivated by "how would from_chars look like if we designed it instead of WG21". That is, an *alternative to* std::from_chars, rather than a *drop-in-replacement for* std::from_chars. Regards, &rzej;

6 6

Review of proposed CharConv
by Antony Polukhin 25 Jan '24

25 Jan '24

## What is your evaluation of the design? Design follows the C++ Standard library design with all the latest additions. Everything is fine. ## What is your evaluation of the implementation? Fine in general. A few nitpicks/concerns follow. ### Arrays of constants RYU/fast_float/... are used for some of the conversions and most of those algorithms have huge tables full of constants. For example https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… and https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… and https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… Those constants have internal linkage. They are put in every translation unit that includes and uses them. Those constants would not be merged by linker. Moreover, the same constants with different names now exist in Standard Library implementations and are not merged with Boost.Charconv. To reduce the binary size and improve data locality I'd recommend switching to std implementation in sources if the feature test macro tells that std::to_chars/std::from_chars are fine. ### Internal headers in include/ Some of the headers are used only internally during build. It seems reasonable to move them to the src/ directory to make sure that no one uses them and that the library itself does not include them by accident. ### Header only support There is a PR to make the library header only https://github.com/cppalliance/charconv/pull/138 This feature is demanded by users however it raises the constants question again. Marking arrays of constants with `inline` should be done to make the constants externally visible, so that the linker could merge them. ### Constexpr for floats Just a feature request - it would be nice to have constexpr from_chars and constexpr to_chars for floating point types. If is_constant_evaluated() - do slow but constexpr conversion. Otherwise - fallback to std:: version or to the implementation in src/ ### Locales Locales are used in some corner cases along with switching them back and forth https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… Looks like there's no need in that line for locales switching. Just get the decimal point separator from the current locale and if it is not '.' then do the replacement of the first '.' to the locale's separator. ### Nitpicks Looks like zero initialization of the buffers could be skipped in following places: * https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… * https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… * https://github.com/cppalliance/charconv/blob/41a83261c0f65aee575e89ccb71d94… ## What is your evaluation of the documentation? Looks like parts of the docs repeat themself. For example, the reference section duplicates some of the previous descriptions. The latter could be just removed. Another thing that catches an eye are the benchmarks. Please also provide some absolute numbers because "X is five times faster than Y" could easily be that X and Y execute for ~1ns each. Those numbers are profitable for users. Side Note for myself: Seems that LexicalCast shows poor performance in some cases where it should not. Will investigate. ## What is your evaluation of the potential usefulness of the library? Very useful for libraries that wish to support pre-C++17 standards or a wide range of compilers. Useful for experimenting and prototyping new C++ Standard Library proposals ## 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? Just looked through the code and the docs. ## Are you knowledgeable about the problem domain? I'm maintaining the Boost.LexicalCast and implemented a bunch of optimizations for std::to_chars/std::from_chars for the libstdc++. I'm not knowledgeable of RUY internals, but have the general understanding of the <charconv>. ## Do you think the library should be accepted as a Boost library? Yes

3 2

Zach Laine CharConv review
by Zach Laine 25 Jan '24

25 Jan '24

- What is your evaluation of the design? It follows the design of the equivalent facility in std::, so this feels moot. No complaints with that part. My only complaint is that the semantics of boost::charconv::from_chars and boost::charconv::from_chars_strict seem backward to me. I know this was mentioned by other reviewers. I think that with near-identity to the standard version, having the same (or corresponding name within boost::) should imply the same semantics. This is classic adherence to The Principle of Least Surprise. I would much prefer that the varying version have the different name, and that the one with the standard's semantics should be from_chars. I also encourage the authors to track any changes to std::from_chars with boost::charconv::from_chars. - What is your evaluation of the implementation? I mean, there's a lot of it. I'm sure it's all necessary, but I only looked at about 10% of it. What I saw seemed reasonable and well organized. - What is your evaluation of the documentation? It's great. The library is smallish, and the docs are correspondingly bite-sized, with plenty of examples. I might add a little more front matter that explains why someone should use this library. The docs get there, but putting it in the first paragraph is better. Busy people will blow right past everything that isn't in the first paragraph or two. - What is your evaluation of the potential usefulness of the library? High. I think the fact that this is a C++17 feature that we still can't reliably use says it all. The fact that it's about the same as the std:: implementation, or sometimes a little faster, is even better. - Did you try to use the library? With what compiler? Did you have any problems? Yes. I tried it with GCC 12, in a small test program just to see it go. No issues. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent about 3 hours, mostly looking at code. I also read all the docs and gave it a quick try. - Are you knowledgeable about the problem domain? Not particularly. I have written lots and lots of parsers, but never a simple low-level one like those in charconv. Zach

3 3

Review of Parser library scheduled
by Mateusz Loskot 17 Jan '24

17 Jan '24

Folk, Review of Zach Laine's Praser library has been scheduled [1] for February 19, 2024 - February 28, 2024 Big thanks to Marshall Clow for volunteering to be the review manager. [1] https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot on behalf of Boost Review Wizards

1 0

Making Boost modular. IMPORTANT! URGENT! <insert-superlative-here>!
by René Ferdinand Rivera Morell 17 Jan '24

17 Jan '24

Dear fellow Boost authors, As some of you may have heard.. Some of us have been working on making it possible to fully consume Boost in a modular arrangement. First some FAQs about this: Q: What is a "modular arrangement"? A: It's when the libraries can be used, and hence built, without creating the monolithic headers, without needing the root build files, and without needing the libraries to be arranged in the usual root/libs/<name>. Q: Will a modular Boost remove the Boost release? A: No. The collection of libraries is still a single release. See recent discussions about this. Q: Will this change the testing? A: No, unless you want to. You will still be able to test the same non-modular way. But you could also test the modular way. Q: Will this require that we change the current Boost source structure? A: Yes. Unfortunately there is one restriction that adhering to a modular Boost requires. We would not allow sublibs. That is, that we can't support having libraries in root/libs/thing/<library> style locations. All libraries must be single libraries under the root/libs directory. Thankfully there's only a handful of such libraries. The root/libs/numeric/* group of libraries. Q: Why do we want a modular Boost? A: I'm not going to enumerate the reasons here. But let me just say.. That we've wanted a way to reduce, i.e. modularize, Boost since at least 19 years ago. When we added the "--without-<library>" build option to the root build file <https://github.com/boostorg/boost/blame/master/Jamroot#L107>. Now the work part.. Over the past year or so I've been making patches to the Boost build files, in my own repo, that cleans up the many, many, problems that make libraries depend on the current source structure. I've also made changes to B2 to make it easier/possible/automatic to deal with the new modular freedom. The B2 changes were naturally easy to put in since I control the repo and distribution. And the last bit of them shipped with the 1.83 release last Summer. But now I need to start pushing the changes to the many Boost repos to get this finished. A couple of weeks ago I started posting PRs to incrementally, and unobtrusively, make the changes to the Jamfiles. So far I have these: <https://github.com/boostorg/ublas/pull/189> <https://github.com/boostorg/interval/pull/38> I'm not sure how else to say this so.. PLEASE, PLEASE, merge those and future PRs ASAP. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

7 12

Boost downloads and JFrog
by Glen Fernandes 13 Jan '24

13 Jan '24

Rather than emails and Slack DMs, I would prefer we have this discussion on the mailing list. To summarize what I have repeated in the aforementioned channels: - Yes, our downloads are not working again because the JFrog account is again not active. - No, I cannot do anything about the JFrog account. - Yes, we can update the website to point to downloads hosted elsewhere. It is correct that JFrog does not charge us yet but our traffic has increased from 60TB/month to almost 200TB/month which is no longer supportable for free. We have limited time to find a solution. We are on borrowed time but as far as I know we still have time. the deactivation of the JFrog account in December 31 was not expected, and it was reinstated. Glen

12 39

Request for comments: to_static_string
by Ruben Perez 13 Jan '24

13 Jan '24

Hi all, Since we will be reviewing Boost.CharConv shortly, and my development efforts in Boost.MySQL are currently requiring converting numbers to strings, I've been playing with the utilities we currently have to do so. I've found cases where I just needed to convert something to string, then pass the result to another function taking a string_view as parameter. The most efficient and correct way to do so is using to_chars (stack based, non-throwing, C++23 constexpr and locale-independent). But I still like the simplicity of std::to_string. Since I had some free time this weekend, I took a step forward and implemented a (deadly simple) wrapper around to_chars that looks like std::to_string, but has all the benefits of to_chars. I called this to_static_string. Repo is here: https://github.com/anarthal/to-static-string This is currently a prototype. I want to hear everyone's opinion on this - do you think this may be useful to any of you? I don't think it's big enough to even consider putting it into Boost (my idea is having it as a standalone lib). Any comments are welcome. Thanks, Ruben.

2 3

[scope] Some random thoughts
by Andrzej Krzemienski 10 Jan '24

10 Jan '24

Hi All, Two observations from reading the docs. Why do I need a condition in scope_exit when I have a scope_fail? I recommend putting warning somewhere in the docs that while using scope guards you may inadvertently read an object after move: std::string checked(std::string name) { scope::scope_exit g{[&]{ std::clog << "checked " << name <<std::endl; }}; validate(name); return name; // name becomes moved-from } Regards, &rzej;

3 5

Forthcoming Boost.Charconv review January 15th - 25th, 2024
by Christopher Kormanyos 09 Jan '24

09 Jan '24

Dear all, The review of Boost.Charconv by Matt Borland is scheduledfrom Monday, January 15th to January 25th, 2024. ----------------------------------------------------- About the library: Boost.Charconv provides a highly portable and efficient, C++11 implementation of <charconv>. The API containsfunctions compatible with <charconv>. Boost.Charconv can be highly useful for portability and efficiency. The standard library's <charconv> requires C++17 or higher. Currently only quite modern compilers such as GCC 11+ and MSVC 19.24+ support both integer and floating-point conversions in their implementation of <charconv>. If you are using either of those compilers, Boost.Charconv is at least as performant as <charconv>, and can be up to several times faster. If you are using an older compiler or a language standard lower than C++17, then there is no <charconv> available. In such cases, Boost.Charconv provides a highly-viable, portable and efficient header-only implementation. Boost.Charconv is a compiled library and does require a few other Boost libraries to run. The docs providedirections for how to consume with b2, vcpkg and Conanto facilitate this. Boost.Charconv fits into Boost stylistically and through itshigh quality, its Boost-like testing and its documentation. Boost.Charconv has been well-received and endorsed on the Boost-lists and is already being used for prototyping in several existing Boost libraries. Tool vendors have expressed interest in Boost.Charconv particularly due to its high performance and clarity of implementation details. docs: https://develop.charconv.cpp.al git: https://github.com/cppalliance/charconv --------------------------------------------------- Naturally, you need not wait until the review formally opens to start reviewing the Charconv library. Please always state in your review whether you think the library should be accepted as a Boost library! Please consider giving feedback on the following general 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 Kormanyos Boost.Charconv Review Manager ------------------------------

2 2

boost.sqlite
by Klemens Morgenstern 06 Jan '24

06 Jan '24

I've written a boost.sqlite library last year mainly to experiment, but it has been a feature-complete C++ wrapper for a while. Hence I'd like to gauge interest to see if it's worth proposing for boost. It has more features than most C++ sqlite wrappers and uses boost-isms such as system.result, tag_invoke and boost.json. Code: https://github.com/klemens-morgenstern/sqlite Docs: https://klemens.dev/sqlite/

5 9

Re: [boost] Interest in new parsing library?
by tobi＠die-loews.de 06 Jan '24

06 Jan '24

Zach Laine wrote: > - use approximately the same set of directives to influence the parse > (e.g. lexeme[]); It seems there is no directive like Spirit's no_case. Is there a way to match case-insensitivity?

2 2

Google Summar of Code 2024 - Collecting Projects & Mentors! 📢
by Inbal Levi 05 Jan '24

05 Jan '24

Hello all! We would like to collect projects & mentors for the GSOC 2024 :) If you would like to volunteer as a mentor and/or have a proposal for a Boost project which you like to collect volunteers for, please fill in the proper tab: https://docs.google.com/spreadsheets/d/1_eUWRsXnhi_JwKZbHZsGQf3WNUESsAPE4lV… Once we have a list of proposed projects, we will upload them to GitHub. Thanks! Best regards, Inbal Levi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Lead Software Engineer @ Millenium* Isocpp, Boost &"Hamakor" Non-Profits Board Member ISO C++ LEWG Chair & Israeli NB Chair C++Now Program Chair & CoreC++ Conference Organizer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Recommendations for documentation authors
by Andrzej Krzemienski 04 Jan '24

04 Jan '24

Hi Boost Developers, And a happy New Year (at least for those who recognize the Gregorian calendar). While I consider improving the documentation quality of some Boost libraries, I wonder if there are any tool or workflow recommendations for the library authors regarding the documentation. I know we do not force any specific tool or format, so I am only asking about recommendations. I note that page https://www.preview.boost.org has at https://www.preview.boost.org/doc/contributor-guide/docs/documentation-guid… the following: > The format for documentation on the new website is AsciiDoc Syntax Quick Reference <https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/>. Should I treat it as a recommendation to use AsciiDoc? I note that quite a few new libraries choose it. I also see the advantage: you need no special tool for it: a simple web browser knows how to format it. But I found the documentation of libraries that use adoc to be uncomfortable to read. I do not know if this is the tool itself or maybe the correlation between the choice of the tool and the devotion to documentation quality, or maybe something else. It is quite subjective. The older libraries' documentation (using BoostDoc) seemed more friendly and easier to navigate. But to write and maintain such documentation is a challenge. Last year something broke in my pipeline (QuickDoc, xstlproc) and to this day I am not able to determine what it is. So, relying on too complex flows, which become obsolete over time, also doesn't seem like a good idea. I wonder if any of you have similar thoughts, and if you can recommend something for writing good quality and user friendly documentation. Regards, &rzej;

9 23

[website][string_ref] Broken link to the library docs
by Andrey Semashev 02 Jan '24

02 Jan '24

Hi, In the library list for Boost 1.84: https://www.boost.org/doc/libs/1_84_0/ there is an entry for Boost.StringRef. However, that library was removed from libs/utility/meta/libraries.json. Or, more precisely, it was renamed to Boost.StringView (key: utility/string_view). The problem is that the StringRef entry in the above list has a broken link to the library docs, and the rename was supposed to fix it (by having an entry for StringView instead, linking to its docs). I'm not sure where StringRef comes from, but can it be removed? This has been reported a few times already: https://github.com/boostorg/website/issues/763 https://github.com/boostorg/utility/issues/105

1 0