- Boost - lists.preview.boost.org

Re: [boost] [Boost-users] Boost Twitter is Blowing Up!!!
by Vinnie Falco 21 Jun '22

21 Jun '22

On Mon, Jun 20, 2022 at 7:48 PM 😉 Good Guy 😉 via Boost-users <boost-users(a)lists.boost.org> wrote: > The problem with Twitter is that it requires an account to read the posts. Yeah, so... my assumption when I made this post is that most folks have a Twitter account. I see that is not the case, even for long-time Boost authors. If you don't already have a Twitter account, there is not going to be much benefit to creating one just to like, follow, and retweet the Boost account, as you will have no followers and thus no reach. Although you might consider creating an account if you want to become more involved in C++ Twitter in general. That said, Twitter and the other socials might not be important to the senior engineers, authors, and maintainers here but collectively, Boost needs to catch up in terms of courting the younger generations of developers. We need fresh blood for library submissions, reviewers, and review managers. Our efforts on social media are aligned with this goal. Thanks

2 3

[JSON] Vote for Boost.JSON in this poll!
by Vinnie Falco 21 Jun '22

21 Jun '22

There's an online poll asking about which JSON library you use. If you use Boost.JSON consider voting for it: <https://meetingcpp.com/mcpp/survey/?q=2> Also, consider voting for it if you _don't_ use Boost.JSON, but you want to. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Boost Twitter is Blowing Up!!!
by Vinnie Falco 21 Jun '22

21 Jun '22

Greetings fellow users, library authors, maintainers, review wizards, release wizards, and Boost Foundation Board members! As part of our ongoing effort to continue the revitalization of Boost, a handful of us have taken the reins to post about Boost on social media. We have postings on Reddit and Hacker news, blog posts about the new efforts in Boost.Unordered, and new tweets. However, we could use your help! Right now the Boost Twitter account has a measly 957 followers. It would be great to increase our reach, so I'm asking everyone if they could be so kind as to Follow the official Boost Twitter account here: <https://twitter.com/Boost_Libraries> and then amplify our messages by Liking and Retweeting. Starting with this pinned tweet, which everyone will see when they visit the Boost Libraries Twittter profile page: <https://twitter.com/Boost_Libraries/status/1539003321939202048> Following the Boost Twitter account will give you up-to-date information about what is going on with Boost, including articles and mentions on other social media sites. Here is what we have so far: <https://www.reddit.com/r/cpp/comments/vfdcrz/advancing_the_state_of_the_art…> <https://www.reddit.com/r/cpp/comments/vbdr3z/new_boostunordered_containers_…> <https://twitter.com/hackernewstop10/status/1538622706035343364> <https://news.ycombinator.com/item?id=31801814> To summarize, engaging with Boost related content on social media will enhance our profile - any help is appreciated! -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

2 1

[thread] upgrade_to_unique_lock takes a upgrade_lock, not an upgrade_mutex
by Phil Endecott 20 Jun '22

20 Jun '22

Dear Experts, boost::upgrade_mutex m; void f() { boost::upgrade_lock l(m); // read shared state g(); } void g() { // precondition: upgrade lock held. boost::upgrade_to_unique_lock l(m); // write shared state } But that's not how it works. The upgrade_to_unique_lock takes the upgrade_lock as its ctor parameter, not the mutex. Is there a good reason for that? I think all that upgrade_to_unique_lock needs to do is to call m.unlock_upgrade_and_lock() in its ctor and m.unlock_and_lock_upgrade() in its dotr, i.e. it doesn't need to access any state in the upgrade_lock. Am I missing something? Regards, Phil.

3 4

multiprecision/gmp.hpp
by Gero Peterhoff 17 Jun '22

17 Jun '22

Hello John, if i include boost::cstdint/float.hpp AND boost::multiprecision::gmp.hpp gets errors in boost::multiprecision::detail::float128_functions.hpp. With the attached patch it works, although I have no idea why this is needed. regards Gero

2 1

[Boost] [Review] [Boost.MySQL] - Review Complete
by Richard Hodges 16 Jun '22

16 Jun '22

Dear All, The submission of Boost.MySQL has created plenty of "lively debate". Unsurprisingly, a library which is based on Asio, of which there are few experts, has given rise to a great deal of questioning around performance, memory re-use, correct return types and so on. It has been noted that Reuben, the library's author, has been very responsive. Both in this mailing list and in terms of raising PRs. A specific concern was raised about the name of the library, and whether it infringed any commercial trade marks. Reuben took the trouble to reach out to Oracle to check. They have responded that there is no infringement and we may use the name. In the end though, despite a great deal of words written raising concerns, ideas and suggestions, we received size reviews, all of which were high quality. The results were: Accept: 3 Conditional Accept: 2 Reject: 1 Having carefully weighed up: - The stated aims of the library - The quality of the implementation - The demonstrated responsiveness of the author - The value of the library to users of MySQL - The value of the library as a teaching tool for implementing a complex, cancellable, asynchronous protocol on ASIO, which correctly adapts to the use of user-selection completion tokens, It seems right to ACCEPT this library into Boost. My congratulations to Reuben. -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

5 5

The deadline for new libraries and breaking changes in Boost 1.80.0 is June 22
by Glen Fernandes 16 Jun '22

16 Jun '22

2022-06-22 closed for new libraries and breaking changes in Boost 1.80. See https://www.boost.org/development/index.html for the full calendar. - The Release Managers

1 0

Boost.MySQL naming
by Ruben Perez 14 Jun '22

14 Jun '22

Hi all, We have received an answer from Oracle's legal team, thanks to Norvald, who initially wrote in this ML and works for Oracle. TL;DR: Boost.MySQL keeps its name. > Naming the library as proposed (Boost.MySQL) is not a problem for a > community connector to MySQL. This is consistent with other naming we > see in the MySQL community and in our experience it has not caused > confusion. We would be concerned about any naming or statements that > suggest an inaccurate association between your library or product and > MySQL, but that does not appear to be the case. So I'm afraid we won't be having Boost.OurSQL anytime soon. Regards, Ruben.

1 0

[container] Contributing 'stationary_vector' to Boost
by Mehrdad Niknami 13 Jun '22

13 Jun '22

Hi all, Happy new year! New mailing list member here. I've developed an STL-style stationary_vector class that retains elements in-place when growing. Very briefly, it is effectively a piecewise-contiguous vector, with the following advantages over vector: - Appending has O(1) overhead in the *worst* case (e.g., push_back() does not move elements) - Insertion and random-access can be done in parallel, as prior iterators & references remain valid This has a variety of benefits, including better UX (no "hiccups" due to reallocations), and the ability to simplify parallel processing of streaming data. It occurred to me the larger C++ community might find this useful. I was wondering if there would be interest in incorporating it into Boost.Container, and if so, what steps I could take to make that happen? I'm of course happy to discuss the design etc. with anyone who might be interested. Summary: https://github.com/mehrdadn/libvital/blob/master/doc/vital/container/statio… Implementation: https://github.com/mehrdadn/libvital/blob/master/include/vital/container/st… Thank you, Mehrdad

7 19

Boost.URL -- some notes
by Andrzej Krzemienski 11 Jun '22

11 Jun '22

Hi Everyone, I am trying to do a review of Boost.URI library (I usually find the official ten-day review period to be too short), and there are a number of interesting things I came across that I thought I would mention. The docs say: > The library requires Boost and a compiler supporting at least C++11. > Even though the library is a candidate for a Boost library, I understand that it is now offered as a "stand alone" version, and this is what the docs describe. I tried to use it with the latest MinGW Distro on Windows ( https://nuwen.net/mingw.html) which uses GCC 11.2 and Boost 1.77. Without success. This is because Boost.URL relies on the component boost::system::result<T>, which is present in Boost.System only since version 1.78: https://www.boost.org/doc/libs/1_79_0/libs/system/doc/html/system.html#chan… First, this is news to me that we have `result<T>` in Boost.System, which has an overlap with result<T, E> from Boost.Outcome. Second, I recommend that Boost.URL docs say that it requires Boost 1.78 or higher. Next, we read: Aliases for standard types, such as string_view > <https://master.url.cpp.al/url/ref/boost__urls__string_view.html>, use > their Boost equivalents. > After reading this, I expected that Boost.URL would use boost::string_view from Boost.Utility library: https://www.boost.org/doc/libs/1_79_0/libs/utility/doc/html/utility/utiliti… But instead, it uses boost::core::string_view, which is an implementation detail from Boost.Core library: https://github.com/CPPAlliance/url/blob/master/include/boost/url/string_vie… Again, this is news for me that Boost has two implementations of string_view. Why? Second, I do not think that Boost.URL should rely on the implementation details of Boost.Core. A better alternative would be to use the official boost::string_view from Boost.Utility. Or is there a good reason not to? Next, the section on the parsers ( https://master.url.cpp.al/url/parsing/url.html) describes the function parse_uri() which returns result<url_view>. What strikes me is this difference: URI (Identifier) in the function name, and URL (Locator) in the return type. I always used the terms URL and URI interchangeably. But now that I see them used in this way in a well designed library, it looks disturbing. The quoted rfc3986 ( https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3) says that an URL is a subset of URI. Now, the name `parse_uri` implies that it will recognize any URI, but on the other hand it is impossible that the result will fit into a url_view, because not every URI is an URL. The synopsis for parse_uri ( https://master.url.cpp.al/url/ref/boost__urls__parse_uri.html) says: Exception safety: throws nothing. > And the line below it says that the function throws std::length_error when the input is too long. It looks like a bug in specs. Later we read: Return value: A result containing the view to the URL, or an error code if > the parsing was unsuccessful. > Which is not precise enough to give me the answer to the URI-vs-URL question. When can a parsing be non-successful? Is it only because it was not conformant to the grammar? The synopsis says "This function parses a string according to the URI grammar below", but is it a URI grammar or a URL grammar actually? Maybe the "return value" section should say instead: Return value: A result containing the view to the URL, or an error code if > the contents of `s` were not conformant with the above grammar. > That is, any other reason for not being successful (if any resources needed to be allocated and failed) may still be reported via exceptions. Now, there is probably a good explanation to the URI vs URL discrepancy. I think it would be good if it was placed in the docs, so that the users don't get confused. While this might look like a list of complaints, I really appreciate the efforts the authors put in creating this library and its documentation. The documentation is really high quality, way higher than the average you will find in GitHub. And this is actually because of this high quality that I am able to spot and report these issues. Regards, &rzej;

11 24