December 2023 - Boost - lists.preview.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 199

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

09 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 9

Paul Bristow
by John Maddock 08 Aug '24

08 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.

6 5

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

3 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

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

Interest in new parsing library?
by Zach Laine 30 Dec '23

30 Dec '23

I'm trying to gauge interest in a parsing library to replace Boost.Spirit 2/Spirit X3. I'm also looking for endorsements. The library is intended to remedy some shortcomings of Boost.Spirit*. I think these are great libraries, but Spirit 2 was written in pre-11 C++ (I think; certainly its dependencies were). Most-to-all of the downsides stem from that -- long compile times, inscrutable compilation failures, etc. (Boost.Parser compile times are quite low.) I'm calling my proposal Boost.Parser, and it follows many of the conventions of Boost.Spirit 2 and X3, such as the operators used for overloading, the names of many parsers and directives, etc. It requires C++17 or later. >From the introduction in the online docs: """ Boost.Parser is a parser combinator library. That is, it consists of a set of low-level primitive parsers, and operations that can be used to combine those parsers into more complicated parsers. There are primitive parsers that parse epsilon (the empty string), chars, ints, floats, etc. There are operations which combine parsers to create new parsers. For instance, the Kleene star operation takes an existing parser p and creates a new parser that matches zero or more occurrences of whatever p matches. Both callable objects and operator overloads are used for the combining operations. For instance, operator*() is used for Kleene star, and you can also write repeat(n)[p] to create a parser for exactly n repetitions of p. Boost.Parser also tries to accommodate the multiple ways that people often want to get a parse result out of their parsing code. Some parsing may best be done by returning an object that represents the result of the parse. Other parsing may best be done by filling in a preexisting data structure. Yet other parsing may best be done by parsing small sections of a large document, and reporting the results of subparsers as they are finished, via callbacks. Boost.Parser accommodates all these ways of working, and even makes it possible to do callback-based or non-callback-based parsing without rewriting any code (except by changing the top-level call from parse() to callback_parse()). All of Boost.Parser's public interfaces are sentinel- and range-friendly, just like the interfaces in std::ranges. Boost.Parser is Unicode-aware through and through. When you parse ranges of char, Boost.Parser does not assume any particular encoding — not Unicode or any other encoding. Parsing of inputs other than plain chars assumes that the input is Unicode. In the Unicode-aware code paths, all parsing is done by matching code points. This means that you can feed UTF-8 strings into Boost.Parser, both as input and within your parser, and the right sort of matching occurs. For instance, if your parser is trying to match repetitions of the char '\xcc' (which is a lead byte from a UTF-8 sequence, and so is malformed UTF-8 if not followed by an appropriate UTF-8 code unit), it will not match the start of "\xcc\x80" (UTF-8 for the code point U+0300). Boost.Parser knows that the matching must be whole-code-point, and so it interprets the char '\xcc' as the code point U+00CC. Error reporting is important to get right, and it is important to make errors easy to understand, especially for end-users. Boost.Parser produces runtime parse error messages that are very similar to the diagnostics that you get when compiling with GCC and Clang (it even supports warnings that don't fail the parse). The exact token associated with a diagnostic can be reported to the user, with the containing line quoted, and with a marker pointing right at the token. Boost.Parser takes care of this for you; your parser does not need to include any special code to make this happen. Of course, you can also replace the error handler entirely, if it doesn't fit your needs. Debugging complex parsers can be a real nightmare. Boost.Parser makes it trivial to get a trace of your entire parse, with easy-to-read (and very verbose) indications of where each part of the trace is within the parse, the state of values produced by the parse, etc. Again, you don't need to write any code to make this happen — you just pass a parameter to parse(). Dependencies are still a nightmare in C++, so Boost.Parser can be used as a purely standalone library, independent of Boost. """ Boost.Parser aims to be a superset of Boost.Spriit* in most ways. Major things missing from the set of features in Spirit 2 + Spirit X3 are: - A separate lexer. - Binary parsers (meaning for parsing bits, not binary numbers written as text; the latter is fully supported). I've been in touch with Joel de Guzman, Hartmut Kaiser, and Michael Caisse, to make sure I was not toe-stomping, for those who are concerned about that. They gave this new library their blessing. One feature comes entirely from them: Boost.Parser is usable in a Boost-free environment -- as a standalone library -- at the user's option. They said that was the #1 request from users, which surprised me a bit. The Github page is here: https://github.com/tzlaine/parser The online docs are here: https://tzlaine.github.io/parser To see an extended example, here's a JSON parser that passes all the published JSON tests, including most of the optional ones, in only about 300 lines of code, go here: https://tzlaine.github.io/parser/doc/html/boost_parser__proposed_/extended_… Finally, for those wanting to know how this lib differs from Boost.Spirit* without digging through the docs, here is the doc page that explains Boost.Parser's relationship to Boost.Spirit*: """ Boost.Spirit is a library that is already in Boost, and it has been around for a long time. However, it does not suit user needs in some ways. Spirit 2 suffers from very long compile times. Spirit 2 has error reporting that requires a lot of user intervention to work. Spirit 2 requires user intervention, including a (long) recompile, to enable parse tracing. Spirit X3 has rules that do not compose well — the attributes produced by a rule can change depending on the context in which you use the rule. Spirit X3 is missing many of the convenient interfaces to parsers that Spirit 2 had. For instance, you cannot add parameters to a parser. All versions of Spirit have Unicode support, but it is quite difficult to get working. I wanted a library that does not suffer from any of the above limitations. It should be noted that while Spirit X3 only has a couple of flaws in the list above, the one related to rules is a deal-breaker. The ability to write rules, test them in isolation, and then re-use them throughout a complex parser is essential. Though no version of Boost.Spirit (Spirit 2 or Spirit X3) suffers from all those limitations, there also does not exist any one version that avoids all of them. Boost.Parser does so. However, there are a lot of great ideas in Boost.Spirit that have been retained in Boost.Parser. Both libraries: - use the same operator overloads to combine parsers; - use approximately the same set of directives to influence the parse (e.g. lexeme[]); - provide loosely-coupled rules that are separately compilable (at least for Spirit X3); and - are built around a flexible parse context object that has state added to and removed from it during the parse (again, comparing to Spirit X3). """ Zach

7 15

Re: [boost] Interest in new parsing library?
by Zach Laine 29 Dec '23

29 Dec '23

On Fri, Dec 29, 2023 at 12:40 PM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Fri, Dec 29, 2023 at 3:53 AM Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > > > > > > > > czw., 28 gru 2023 o 22:05 Zach Laine via Boost <boost(a)lists.boost.org> napisał(a): > >> > >> I'm trying to gauge interest in a parsing library to replace > >> Boost.Spirit 2/Spirit X3. I'm also looking for endorsements. > >> > [snip] > > > > Hi Zach, > > Thank you for writing and sharing this library. I intend to test it on my mini-language early next year. > > That sounds useful. Please let me know how it goes. > > > For now, let me dig a bit about the high-level differences between Boost.Parser and Boost.SpiritX3. > > > > Your introduction mentions "a separate lexer" as a feature that Boost.Spirit is missing. > > How does that square with the entire section for Spirit.Lex in Boost.Spirit docs? > > No, I meant the other way around. *Boost.Parser* is missing that. > Sorry for the confusion. > > > "Boost.Parser aims to be a superset of Boost.Spirit". But Boost.Spirit is also a generator. > > Quite right! I forgot about that; this is another thing that > Boost.Parser is missing vs. Spirit. > > > You mention that "Spirit X3 has rules that do not compose well". I personally never experienced this. Is there an example somewhere that would illustrate this problem? > > The issue for me is that the attribute types generated by X3 parsers > and rules are loose. This is by design. So, say you have a parser > that parses strings, producing a range of char: > > auto p = /* ... */; > > If you then use p to parse into some std::string variable in the > middle of the parse, everything works as you'd expect. But if you use > p to parse into a different std::vector<char> variable in the middle > of the parse, that also works. This is not by itself a problem. > However, I had a problem with this semantic, because there was no way > to lock down the attribute type to a specific, concrete type. So if > at some point in the parse I had: > > auto p_p = p >> p; > > That may be used to generate a std::variant<std::string, > std::vector<char>>, a std::variant<std::vector<char>, std::string>>, > etc. These types are not interconvertible. So, If you made a mistake > somewhere in writing a semantic action or something, you get an error > stating that std::variant<std::string, std::vector<char>> is not > assignable to std::variant<std::vector<char>, std::string>> or > whatever, and figuring out where the error actually lies is very > difficult. If you have a Boost.Parser rule, it has a concrete > attribute type A, and so it always produces As. I find this much, > much easier to diagnose and debug when I make a mistake. > > > What is the recommendation of Boost.Spirit authors to the programmers that need to do parsing? Is Boost.Parser simply the newer and improved version, or do they have disjoint sets of use cases? > > I think Joel answered that above. > > > Personally, skimming through the docs, I find the feature of producing custom error and warning messages very attractive. This is what I was always missing from the parsing libraries. > > > > Thanks again for your effort. > > Thanks for taking a look! Also, I should mention that this is the > easiest library I have ever written, given its complexity. That is > true due to all the very nice design work that came before it, from > Joel, Hartmut, and others. > > Zach I somehow sent only this one reply to Andrzej only; echoing here. Sorry for the borked formatting. Zach

1 0

About weird behavior with boost.asio 1.63 on linux 2.6.15
by Scott Zhang 25 Dec '23

25 Dec '23

Dear All: I have been using boost over 10+ years. The asio library work quite well along with document. Today I get a problem: My development environment: gcc 4.7.3 OABI Linux 2.6.15 boost 1.63 The code looks like below: void myTask(const char *text) { sleep(5); /*for(;;) { //sleep(1); }*/ cout<<"text is "<<text<<endl; // cout<<"out"<<endl; } boost::asio::io_service ioService; ioService.post(boost::bind(myTask,"hello")); ioService.run(); I get 2 problems: 1. If I run program as above, the mytask get executed correctly, but as soon as it returns, the program get "illegal instruction", and program dies. If I call myTask directly, then everything is ok. So what's wrong with io_service.post 2. If I run ioservice within thread using threadpool.create_thread( boost::bind(&boost::asio::io_service::run, &ioService) Then after myTask executed, I get "Killed", using strace says program get SIGKILL. As the test code is so simple, I can't tell where goes wrong. I also noticed, if I don't call io_service.post, everything looks ok. And the threads, in linux ps, shows as many processes. I reread the document of asio 1.63, it says had beed tested against linux 2.4 and 2.6 kernel. so it should be ok. Please help. Thanks.

3 5