February 2024 - Boost - lists.stage.boost.cppalliance.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

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

Reminder: Review for Zach's parsing library starts on Feb 19th
by Marshall Clow 11 Mar '24

11 Mar '24

That’s a week from now. Github: https://github.com/tzlaine/parser Docs: https://tzlaine.github.io/parser — Marshall

14 54

Late review of Boost.Parser
by David Sankel 02 Mar '24

02 Mar '24

# Are you knowledgeable about the problem domain? Yes. I've written several parser combinator libraries in C++ and used still more in C++ (Spirit v1, v2, and qi) and other programming langauges (Haskell's Parsec, attoparsec, and others). # How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read through the tutorial documentation and some of the reference documentation. I also tried to create several examples with the library and made comparisons to Haskell's Parsec. # What is your evaluation of the potential usefulness of the library? Very # What is your evaluation of the documentation? The documentation isn't great. Consider char_ <https://tzlaine.github.io/parser/doc/html/boost/parser/char_.html>'s documentation. It includes no examples and fails to mention it can be used without arguments. It seems strange that the tutorial focuses so much on semantic actions. It seems like the more common case would be to parse into some kind of abstract syntax tree. # What is your evaluation of the design? Much of the wealth of research into parser combinators wasn't incorporated into this library. I didn't see in the documentation, for example, an easy way to "map" one parser's attribute into another. This kind of thing should be a basis operation provided by the library. # What is your evaluation of the implementation? The usage of has_include is a ODR nightmare for large codebases. It would be better to generate some kind of config.hpp that sets these definitions at compile time. For custom variant/tuple types, user specialization of variable templates is also an ODR nightmare. Again, a config.hpp would be better for this. For this, though, I don't think the configurability is worth the complexity. We have standard types for these so we should use them. # Did you try to use the library? With what compiler? Did you have any problems? Yes, I tried to use the library with a modern compiler on a MacOS machine. I didn't have any problems building. # Do you think the library should be accepted as a Boost library? No, I do not think it should be accepted. Overall, I think the syntax has too much focus on magically filling in user-provided structures instead of the basics of monadic parser combinators and basis operations. Consider the following Haskell parser which evaluates simple parenthesized sum expressions. I wasn't able to use Boost.Parser to accomplish this after reading the documentation and several attempts. I'm sure it's possible, but I don't see how it can be done using the combiners and primitives provided. import Text.Parsec.String (Parser)import Text.Parsec integer :: Parser Integerinteger = do n <- many1 digit return (read n) integerPlus :: Parser IntegerintegerPlus = do x <- integer y <- (try $ char '+' >> expression) <|> return 0 return $ x+y parentheses :: Parser Integerparentheses = do char '(' x <- expression char ')' return x expression :: Parser Integerexpression = integerPlus <|> parentheses

5 9

Boost.Parser parsing length-prefixed strings efficiently
by Mohammad Nejati [ashtum] 01 Mar '24

01 Mar '24

Hi everyone, I have two questions about the following code, which attempts to parse length-prefixed strings using the proposed Boost.Parser: ``` std::string input = "[5]HELLO[5]WORLD"; unsigned int size = 0; auto action = [&size](auto & ctx) { size = bp::_attr(ctx); }; auto lps_parser = '[' >> bp::uint_[action] >> ']' >> bp::repeat(std::ref(size))[bp::char_]; auto result = bp::parse(input, *lps_parser); ``` 1. Is it possible to eliminate the need for the action and size variable by using some kind of placeholder in bp::repeat that utilizes the attribute of the first parser? 2. How can we make this part of the parser more efficient: bp::repeat(std::ref(size))[bp::char_] The current implementation seems to loop and execute bp::char_ parser on each character, while all it needs to do is chunk a portion of the input string. Regards, Mohammad Nejati

2 1

New website is open-source!
by Vinnie Falco 29 Feb '24

29 Feb '24

The new website and documentation are provided under the BSL, and the source repositories have been transferred to the Boost GitHub organization: https://github.com/boostorg/website-v2 https://github.com/boostorg/website-v2-docs While we sort out the unresolved issues related to the licensing of artwork and logo, the new website has moved to this temporary location for now: https://boost.io Please continue to experience, enjoy, and most importantly test the new website. A gentle reminder: it is not “finished” and likely will not be “perfect” for a while. The launch of the new website is the beginning of the journey rather than the end. Issues opened here will be acted upon by our dedicated website development team: https://github.com/boostorg/website-v2/issues For documentation-related issues, please open and monitor issues here: https://github.com/boostorg/website-v2-docs/issues Pull requests are always welcomed! Thanks

6 6

Boost.Parser questions
by Ruben Perez 29 Feb '24

29 Feb '24

Hi all, Sorry for jumping into this so late. I'll send my review tomorrow (that's still on time, isn't it?). I've been playing with the library and some questions popped up (please note I've no prior experience with Spirit): * What's the rationale for using operator[] for semantic actions (instead of a regular method like .action())? It looks like the parsing problem with inline lambdas could be easily worked around with this. * What's the rationale for using operator[] for directives? repeat(24)[p] looks like an over-complication, where a regular function repeat(24, p) would have just worked fine. * For non-recursive rules, what's the rationale on preferring the macro over something like: constexpr bp::rule<struct replacement_field_tag, std::string> replacement_field { "replacement_field", +bp::char_ }; * My use case involves parsing identifiers that can only contain ASCII lowercase, uppercase, digits and the underscore. I'd usually do this by defining a `bool is_identifier_char(char c)` function. This is what I could do with Boost.Parser - is there a better way (one that doesn't force me to list all valid characters)? constexpr const char name_chars[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789"; constexpr auto name_continuation_rng = std::span<const char>( name_continuation, sizeof(name_continuation) - 1 ); * What's the rationale behind the special naming convention for functions like _attr, _value, _globals and the like? Is there a reason why these can't be member functions of the context? * I've found really frustrating the generic lambda approach for semantic actions, since this completely inhibits tooling like clangd. Is there a reason why we can't have a public definition of the parsing context I could use in my functions? * I started my evaluation using clang-18 (Linux) but builds fail (seems to happen under all clang versions I tried). gcc-12 seems to work fine. Note that I'm using the develop branch, since I understand it contains the bug fixes for the issues that previous reviewers found. Regards, Ruben.

6 9