September 2022 - 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

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

New Library Proposal: xvec/simd
by Towner, Daniel 17 Oct '22

17 Oct '22

I would like to propose a SIMD/data-parallel header-only library for inclusion in boost. The library is an example implementation already developed by Intel of a C++ TS proposal called std::experimental::parallelism_v2::simd [1]. The library is styled as a data-parallel library where the programmer specifies the data parallelism available in the source program, and the compiler will generate the appropriate simd instruction sequences. The library is agnostic of simd element type and length, and within reason, should be able to target any processor with simd capabilities. Intel has added further generic extensions to the proposal, such as permutation operations and support for complex numbers [2]. Motivation: The concept of simd needs little introduction as the technique is widely used in high performance software and there are many libraries providing varying level of abstraction and portability. In [1], Matthias Kretz made a proposal to provide a standard C++ library which implements many data-parallel concepts in a portable, vendor-neutral style, and with tight integration with C++ (e.g., operator overloading, overloads for all appropriate standard library functions). That proposal and the feedback on it have been discussed in WG21 and Intel supports the proposal. There was an attempt to add a boost.simd library in the past but that was abandoned after its authors decided to commercialise it. Despite the availability of other simd or data-parallel libraries in the wider community there is still a gap for a data-parallel, width-agnostic, vendor neutral library with close integration into C++. The std::simd library proposal and its example implementation from Intel seem to fill this gap. The existence of an example implementation in boost will also make it easier to get users to adopt the TS and provide feedback to improve its API and feature set for real-world code. History: There are two strands of history that come together in this proposal: Intel's own vector libraries, and the C++ std::simd proposal. Intel has a long history of developing simd-capable processors and has its own libraries for accessing simd features [3]. A recent Intel project to refresh those libraries resulted in a new library called `xvec' which incorporates many modern C++ features and is deliberately vendor and target neutral, with the target being selected at compile-time. In 2013 the proposal was started, and then a C++ TS was published in 2018 [1] and discussed in WG21. Due to the similarities of the two libraries and their common goals, myself and Matthias Kretz are now working together on merging the simd specification from the Parallelism TS 2 into the IS for C++26. Status and Implementation: The `xvec' example library implemented by Intel supports most of the features of the std::simd proposal [1], along with a number of extensions to add some capabilities (e.g., generic permutation, complex number support) [2]. The library works in Linux and Windows, and can be compiled with GCC 12, LLVM 14 and Intel's oneAPI 2022. It is currently tested using googletest. Most of the library is implemented on top of the LLVM and GCC vector extensions [4], which makes it compilable on any target supported by those extensions. In a limited number of places intrinsics are used to access specific Intel instructions, but efficient generic fall-backs are also provided for simd targets which don't have those instructions (and this can included unsupported Intel processors too). Request: I would welcome any comments, questions or ideas on how to proceed with this proposal. [1] ISO/IEC TS 19570:2018, Programming Languages - Technical Specification for C++ Extensions for Parallelism, by Matthias Kretz. http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/n4808.pdf [2] P2638R0: Intel's response to P1915R0 for std::simd parallelism in TS 2. https://wg21.link/p2638r0 [3] https://www.intel.com/content/www/us/en/develop/documentation/cpp-compiler-… [4] https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-ve…

5 8

[checking interest] boost.tcl
by Klemens Morgenstern 01 Oct '22

01 Oct '22

Is there any interest in C++ Tcl bindings? I wanted to find out how far I can push boost.describe so I create C++ tcl binding based on it, PoC is here https://github.com/klemens-morgenstern/boost.tcl It's currently a rough PoC so it'd be a lot of work to make this a proper boost library, hence the question if there's some actual interest, otherwise it's a nice toy project. All you need to do is to use boost.describe for your enum or class and then you can use them in tcl: // C++ enum test_enum {foo = 1}; BOOST_DESCRIBE_ENUM(test_enum, foo); struct my_class { double foo; void bar(int); }; BOOST_DESCRIBE_STRUCT(my_class, (), (foo, bar)); BOOST_TCL_PACKAGE(Test_module, "1.0", mod) { auto & cmd = boost::tcl::create_command(mod, "test"); auto & enm = cmd.add_subcommand("enum"); enm.add_enum<test_enum>(); auto & fun = cmd.add_subcommand("add").add_function(+[](int i, int j) {return i + j;); auto & cl = cmd.add_subcommand("add") .add_class<my_class>() // adds all the members based on boost.describe .add_constructor<my_class(int, std::string)>(); } # TCL # create `test_enum` from it's int valid set e1 [test enum 1] # create test_enum from it's name set e2 [test enum foo] # call the function - overloading is supported [test add 1 2] # create an instance of my_class set mc [my_class new 1 test-string] # get a data-member puts [ *$mc .get foo ] # call a method *$mc bar 42

5 4

Re: [boost] [Boost-users] [signals2][variant] inline warning with MSVC 2022
by Frank Mori Hess 23 Sep '22

23 Sep '22

On Wed, Sep 21, 2022 at 12:21 PM Frank Mori Hess <fmh6jj(a)gmail.com> wrote: > > On Mon, Sep 19, 2022 at 3:16 AM Gavin Lambert via Boost-users > <boost-users(a)lists.boost.org> wrote: > > > > >,struct boost::mpl::l_iter<struct boost::mpl::l_end> > *)' marked > > as __forceinline not inlined > > > > I'm not sure whether the Real Bug™ is in signals2 or in variant, but I > > don't think it's in any of my code since it doesn't name any of my types > > above that I can see. > > The problem is not in signals2, as it makes no direct use of > __forceinline. variant does make use of BOOST_FORCEINLINE so it > probably needs to have the pragma suppression added somewhere. > Actually, maybe the easiest thing would be to just put the pragma suppression in the header that defines BOOST_FORCEINLINE (config/detail/suffix.hpp). -- Frank

5 13

[codecov] blowing up like the Hindenburg
by Vinnie Falco 20 Sep '22

20 Sep '22

All: Over the last 15 months, codecov.io has been undergoing a refactoring/rewriting of its user interface and in my opinion it is not for the better. There is a significant loss of functionality and the interface designs which have replaced the old designs are less usable. There's been an open issue for receiving feedback: <https://github.com/codecov/Codecov-user-feedback/issues/1> As you can see a lot of people are having problems. I have scheduled a call with the CEO. My purpose for this thread is to identify other Boost authors, maintainers, and users who have a stake in seeing codecov preserve its functionality and not get worse. And to show where you can go and complain if you are so inclined. Sam is investigating coveralls as an alternative solution. Its UI isn't quite as good as the old codecov. But it is better than the new codecov. Happy to hear anyone's thoughts on this matter. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

3 5

[range] Concept check failing with custom C++20 range support
by Jared McIntyre 20 Sep '22

20 Sep '22

I've been toying around with a pull request that was entered against boost::range to support integration of boost range_v2 and C++20 ranges to see how flexible it would be: https://github.com/boostorg/range/pull/123 I have a need to continue to use boost::any_range in some of our interfaces, but it would be nice to switch to using C++20 ranges under the covers. A lot of it seems to work well with the type definitions from the pull request, but I'm running into an issue with concept check on line 228 or any_iterator_wrapper.hpp specifically when using the transform adaptor. I don't have the same issue with boost::adaptors::transformed. What has me confused is that I think that the result views::transform should be forward traversal, but I'm not really clear on exactly why it is failing. I created a test if anyone wants to play around with it in a compiler and help me understand what is going on: https://godbolt.org/z/1hMsofbrv Switching between the two commented out base_range declarations will get you different results. Here is the code for anyone that just wants to look at it here: #include <boost/range.hpp> #include <boost/range/adaptors.hpp> #include <boost/range/any_range.hpp> #include <ranges> #if 1 namespace boost::range_detail { template< std::ranges::common_range C > struct range_mutable_iterator< C > { typedef std::ranges::iterator_t< C > type; }; template< std::ranges::common_range C > struct range_const_iterator_helper< C > { typedef std::ranges::iterator_t< C const > type; }; } #endif int main() { std::vector<int> vec(5, 0); auto mul2 = [](int i) { return i * 2; }; auto base_range = vec | std::views::transform(mul2); //auto base_range = vec | boost::adaptors::transformed(mul2); boost::any_range<int, boost::forward_traversal_tag> new_range = base_range; }

1 0

[dynamic_bitset] Add iterator feature
by GaoZIYU 11 Sep '22

11 Sep '22

I would like to support iterator feature by adding a few member functions, `begin()`, `end()`, `rbegin()`, `rend()` and their corresponding constant version. I think it's necessary for dynamic_bitset to have this feature through my thinking and other developer's opinions ( https://m.weibo.cn/5027267375/4757345970424490) Now I have submitted a pull request for the feature with code, docs and test case. Please review my code at your convenience. Thanks!

1 0