August 2020 - 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.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

Adding my sorting algorithm, ska_sort, to boost, attempt 2
by Malte Skarupke 24 Nov '21

24 Nov '21

Hi everyone, I started a discussion about this in October, but at the time the maintainer of the sort library was busy, then I was busy, so now it's January... I wrote a generalized version of radix sort a couple years ago and gave a talk about it here: https://www.youtube.com/watch?v=zqs87a_7zxw I would like to get a new version of that sorting algorithm into boost. It's faster than what I showed several years ago. It's also even more general and has a new interface that should be easier to extend. I uploaded the code here: https://github.com/skarupke/sort/tree/master The documentation is also already updated with new benchmark results. Let me know what's required to get this into boost. Would you like this in the form of a pull request? One of the big things that probably needs review is the interface, since radix sorting works differently than comparison based sorting. For most normal uses you just need to provide a sort key, but more complicated cases can get more complicated. I tried very hard to make everything easy, but I'd also be curious if others can come up with better ways of doing the interface. Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

8 10

[LEAF] Review Results
by Michael Caisse 09 Sep '20

09 Sep '20

I want to thank Emil for his patience for the publishing of the review results as life got in my way. Thank you Emil for submitting LEAF to be reviewed for inclusion into Boost. As an already-Boost-author, you knew what you were getting into and continued into the process. I also want to thank you for once again pushing our thoughts on error handling. -------- Result -------- This is the part everybody scrolls to the bottom to read, so let’s just put it at the top. Boost.LEAF is ACCEPTED into Boost. After the following modifications are made to the library, the repository can be transitioned to Boost for inclusion into the next release (with the release cycle timing constraints): Specify the TLS requirement sooner in the documentation. Optional usage of Boost.Config to perform all of the Boost Configy things. (further discussion on this below) Macro naming and general Boostification clean-up. -------- Reviews -------- There was a good amount of discussion about the library on both the dev and user mail lists. I want to personally thank those who got involved in the review. You make the process work! Result summary: Accept: 7 Reject: 1 No-decision: 3 The no-decision reviews provided valuable input and discussion threads. While it would be my preference to have the review authors provide a final verdict, I was grateful for the time and energy they spent with the library and formulating thoughts into emails for discussion. Some comments from reviews: “I find function preload() really great and novel. … This really makes the error reporting code brief, clean and bug-free.” “I like LEAF very much and there's a lot offered here…” “I like it.” “...it allows bridging multiple error handling strategies and usage patterns in an efficient way.” About the docs: “They look good and manage to explain hard concepts in a very approachable fashion.” “The documentation is great -- in terms of styles it's probably the best I've seen for a C++ library.” “Clear, friendly and complete.” -------------- Some Thoughts -------------- While there was overwhelming consensus that LEAF should be included into Boost, the process is not democratic. I have spent considerable time understanding the concerns raised in each of the reviews and in particular the singular rejection. Emil took time responding to each of the reviews. The exchanges were fruitful and both “conditional accept” and “reject” reviewers changed their verdicts to accept along the way. Most of the concerns were amicably resolved. I am comfortable with the design choices and implementation made by the author for the remaining items. One reviewer brought up the re-implementation of Boost.Config type facilities. This of course is a complex issue for a library with zero dependencies. The ability to simply drop the Boost.LEAF directory into a project and run is a definite plus for a specific user segment. Being able to modify a single Boost.Config repository to support WackyCompiler14 targeting LEG Core and get a bunch of libraries for the ride is also a plus. Emil and I have discussed these concerns and the best choice seems to be defaulting to zero dependencies and the option to pull in Boost.Config to provide configuration type facilities if needed. Accepting a library into Boost is as much about the library as it is bringing the author into a group. While Emil is already part of the author crowd, it was clear to me through his careful, informative, and patient responses that the addition of Boost.LEAF brings professional maturity that strengthens the community. A user with more than a year of experience with the library voted acceptance based on the “qualities of the library itself and the responsiveness and openness for feedback of its author.” Throughout the review period, Emil integrated feedback to both the documentation and code in another branch. It was wonderful to see the community provide input and the author respond so quickly to produce a better final result. Thank you Emil for your vision of better error handling and striving to bring us along! -- Michael Caisse Ciere Consulting ciere.com

3 2

ASIO: Same code for tcp, unix domain sockets (websockets via beast)
by Matthias Loy 26 Aug '20

26 Aug '20

Hello, we are implementing a service that is to be available via tcp, unix domain sockets (and websocket). Websocket might be out of scope since it is not part of asio. All those protocols are streaming protocols and should behave in the same way: read some bytes, write some bytes. I would like to have the code implemented only once to handle several protocols. Not having one for local::stream_protocol::socket and another one for ip::tcp::socket. Until now I was not able to find something like base classes that allow me to do that. I only found code that works for tcp or unix domain sockets (local). The protocol is not to be decided at compile time but on runtime. Hence I'm having problems using templates here. The documentation of async_read states that the stream has to support the AsyncReadStream concept. Is there a way to get something supporting this concept from local::stream_protocol::socket and ip::tcp::socket? Best regards, Matthias

4 3

JSON library scheduled for review
by Mateusz Loskot 25 Aug '20

25 Aug '20

Hi, A brief announcement from the review wizards: Formal review of the JSON library has been scheduled to take place between October 9 and October 18, 2020. Details and links available here https://www.boost.org/community/review_schedule.html We'd like to thank Pranam Lashkari (Boost.GIL, [Boost.]Astronomy, Boost GSoC) for volunteering to act as the review manager. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Shallow Hal Needs A Gal!
by Vinnie Falco 25 Aug '20

25 Aug '20

And Boost.JSON needs a review manager! -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

3 4

Modules
by Damian Vicino 24 Aug '20

24 Aug '20

Hi, Are there any guidelines on the use of modules inside boost? Are we planning any steps for adoption of them?

9 18

You Won't Believe This!
by Vinnie Falco 23 Aug '20

23 Aug '20

But Boost.JSON needs a Review Manager! Don't be shy now! Repository: https://github.com/cppalliance/json Documentation: http://vinniefalco.github.io/doc/json/index.html -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

7 10

[release] Boost 1.74.0 Release Candidate 1
by Marshall Clow 21 Aug '20

21 Aug '20

The first release candidates for the 1.74.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.74.0/source/> The SHA256 checksums are as follows: 9ea3fc8573413f4d4b2c4d448110b6cb0467df834304112e143c7edb09ae71e9 boost_1_74_0_rc1.7z 8b6c429a41f7cac1880594adf8d1d6f0cc1cf19f8980c6b86ac38ef8b3d8a4e0 boost_1_74_0_rc1.tar.bz2 a0a96a9bb3863863e034cafc825b2ddba4249c7d278b76df1277295e7c7afbf2 boost_1_74_0_rc1.tar.gz d4f31cce9d5fbd55691dc2f5fb73380e95aa66426c891ceb3ebdfc6616022842 boost_1_74_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

6 10

[Core] gdb/VS Pretty-printers for Boost
by Jeff Trull 21 Aug '20

21 Aug '20

There's been a number of independent efforts to produce pretty-printers (or "visualizers") for different popular Boost libraries. The one I like most due to its thoughtful execution is probably this one <https://github.com/ruediger/Boost-Pretty-Printer>. But maintaining a set of pretty-printers out of tree is a challenge for all the usual reasons. Having libraries optionally supply and maintain them is much more sustainable. Would it be possible to define a small set of standard ways (file locations, build steps) for a library to store and install pretty-printers for gdb and/or Visual Studio? Thanks, Jeff

7 10

achriving multiple files under a folder
by ravi shankar 20 Aug '20

20 Aug '20

Hi All, Is there a possibility to archive multiple files present under a directory into a single archive file using boost libs. folder structure: folder1 / \ folder2 file2 / file1 Please help me in this regard.

1 0

PFR (Precise and Flat Reflection) by Antony Polukhin scheduled for review
by Mateusz Loskot 18 Aug '20

18 Aug '20

Hi, A brief announcement from the review wizards: Formal review of Antony's library has been scheduled to take place between September 28 and October 7, 2020. Details and links available here https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[container] devector merged into Boost.Container
by Ion Gaztañaga 17 Aug '20

17 Aug '20

Hi to all, Many years after the review (it was finished in 2017), I managed to find some time to make the review result possible and integrate double-ended library's "devector" class in Boost.Container. I merged the implementation some days ago in develop branch and I hope we can merge it to master soon. Several changes were needed (C++03 support, similar interface/features to other containers, removed some non-essential operations that were not present in other containers...) to do a proper integration. It's might not be production-ready, documentation might be still lacking, but I think it's a good starting point. Initial performance benchmarks seems to show I haven't broken anything important;-) I made no changes to original devector's main design, no experiments with growth or data movement policies. There were many good ideas in the review and outside boost we have experiments worth trying. Examples: - https://lists.boost.org/Archives/boost/2017/10/239316.php - http://larshagencpp.github.io/blog/2016/05/22/devector I also plan to slowly start sharing more implementation details between devector and vector to avoid code duplication and ease maintenance, and adding some missing operations in devector that are in vector (like default initialization insertions). Many thanks to Benedek for his patience, and great design/implementation (including a detailed test-suite, absolutely essential to ease the work I needed to do to integrate devector in the library). Better late than never ;-) Best, Ion

5 6

Embarcadero C++ clang-based PRs
by Edward Diener 15 Aug '20

15 Aug '20

There are still 9 Boost libraries which have not accepted my individual PR for the library which would enable the Embarcadero C++ clang-based compilers ( bcc32c, bcc32x, bcc64 ) to work with those libraries. These libraries are: circular_buffer - https://github.com/boostorg/circular_buffer/pull/34 graph = https://github.com/boostorg/graph/pull/215 iostreams = https://github.com/boostorg/iostreams/pull/112 parameter = https://github.com/boostorg/parameter/pull/103 program_options = https://github.com/boostorg/program_options/pull/94 thread = https://github.com/boostorg/thread/pull/317 typeof = https://github.com/boostorg/typeof/pull/18 units = https://github.com/boostorg/units/pull/47 unordered = https://github.com/boostorg/unordered/pull/16 1) None of these PRs affect any compilers but the Embarcadero C++ clang-based compilers. I can guarantee that. 2) None of these PRs change the logic of any of the libraries in any way. 3) All the PRs will allow the Embarcadero C++ clang-based compilers to not be subject to workarounds in these libraries for the old Borland/Codegear/bcc32 compiler, to which the Embarcadero C++ clang-based compilers are not related in any way. 4) All the PRs have passed all the CI tests which had not already been previously broken by the CI setup for the library itself. You can see my comments about any of the failing CI tests and why they have absolutely nothing to do with the PR for the library. If some maintainer who has write access to any of these libraries could merge any of these PRs it would most appreciated by me. Thank you !

2 1

[release] Boost 1.74.0
by Marshall Clow 14 Aug '20

14 Aug '20

Release 1.74.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.74.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.74.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse, Glen Fernandes

2 1

[release] 1.75.0 open for merging
by Marshall Clow 14 Aug '20

14 Aug '20

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html [ Note: this will be updated later today ] Release schedule explanation: https://github.com/boostorg/wiki/wiki/Releases%3A-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[test] runtime failures with "main() should return report_errors()"
by stefan 14 Aug '20

14 Aug '20

Hello, With the Boost.Python tests I'm observing a couple of mysterious failures, where the test application fails *after* the actual test succeeded, with a message main() should return report_errors() I gather this error is emitted by the Boost.Lightweight_test library whenever a test's main() function does not call `report_errors()` at the end. The problem in my case is that my failing tests are not (explicitly) using Boost.Lightweight_test. In fact, in all of the failing cases I'm not even writing a `main()` function, as the test driver is a Python script that's importing a (test) module. For example: https://www.boost.org/development/tests/master/developer/output/teeks99-05-… Does anyone understand or has an idea how this could happen, and how to fix this ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 2

current situation with clang-cl?
by Dennis Luehring 13 Aug '20

13 Aug '20

some of my project using boost building with clang-cl but there are still some libraries that don't is there any official interest in supporting clang-cl or is it up to a library maintainer to support it? many project of mine building better and better, boost 1.73 currently is neary full useable with clang-cl without any problems today i tried to compile a 600KLOC project and it failed with the same problem Libreoffice got they are using a patch to "fix" its used boost version https://github.com/LibreOffice/core/blob/62808ef28e05eee4945a6a15d981350d13… https://github.com/boostorg/thread/issues/286 "clang-cl defines _MSC_VER by ms-compatibility but BOOST_MSVC will not be set." still a problem? there are some Issues reported but i don't know if fixes are wanted of if there is a strategy to support clang-cl out of the box

4 13

Re: [boost] using clang-cl with 1.74-rc2 forces auto-link to search for clangw10 libs instead of using existing Microsoft-cl built libs
by pbristow＠hetp.u-net.com 12 Aug '20

12 Aug '20

> -----Original Message----- > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Dennis Luehring via Boost > Sent: 12 August 2020 14:59 > To: boost(a)lists.boost.org > Cc: Dennis Luehring <dl.soluz(a)gmx.net> > Subject: [boost] using clang-cl with 1.74-rc2 forces auto-link to search for clangw10 libs instead of using > existing microsoft-cl built libs > > using latest VS2010 and llvm/clang 10.0.0 release (10.0.1 is a litte bit more recent but no windows builds > available) Aside: WinLibs standalone build of GCC and MinGW-w64 for Windows at Winlibs.com has very recent builds, mainly intended for Mingw-64, but often OK for Windows clang-cl too? (I am using Clang and GCC from this site with CodeBlocks IDE and also using b2/bjam but I could not get the clang-win .exe to build reliably and am using clang-linux .exe in my user-config.jam. However this isn't any help to your difficulties ☹ ). > compiler set to 2017 microsoft-cl in VS2017: > libboost_serialization-vc141-mt-gd-x32-1_74.lib > > compiler set to clang-cl in VS2017: > libboost_serialization-clangw10-mt-gd-x32-1_74.lib > > that behavior is new to 1.74 - older boosts versions 1.69..1.73 would use the vc141 libs what makes > sense because clang-cl is the microsoft-cl compatible replacement > > normaly there is no need to switch any external libs when using clang-cl instead of microsoft-cl

1 0

using clang-cl with 1.74-rc2 forces auto-link to search for clangw10 libs instead of using existing microsoft-cl built libs
by Dennis Luehring 12 Aug '20

12 Aug '20

using latest VS2010 and llvm/clang 10.0.0 release (10.0.1 is a litte bit more recent but no windows builds available) compiler set to 2017 microsoft-cl in VS2017: libboost_serialization-vc141-mt-gd-x32-1_74.lib compiler set to clang-cl in VS2017: libboost_serialization-clangw10-mt-gd-x32-1_74.lib that behavior is new to 1.74 - older boosts versions 1.69..1.73 would use the vc141 libs what makes sense because clang-cl is the microsoft-cl compatible replacement normaly there is no need to switch any external libs when using clang-cl instead of microsoft-cl

1 0

[release] Boost 1.74.0 Release Candidate 2
by Marshall Clow 12 Aug '20

12 Aug '20

The second release candidates for the 1.74.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.74.0/source/> The SHA256 checksums are as follows: 903fd40074de8dc733d2f0b6b0642e43b714653eaeb79289b12161b9567fae97 boost_1_74_0_rc2.7z 83bfc1507731a0906e387fc28b7ef5417d591429e51e788417fe9ff025e116b1 boost_1_74_0_rc2.tar.bz2 afff36d392885120bcac079148c177d1f6f7730ec3d47233aa51b0afa4db94a5 boost_1_74_0_rc2.tar.gz a0e7ce67c52d816708fdeccdd8c9725626ba61254c13c18770498cacd514710a boost_1_74_0_rc2.zip Changes from RC1: * Fix a recently introduced bug in Boost.Asio where it would read from uninitialized memory. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

3 3

[release] Boost 1.74.0 beta 1 released
by Marshall Clow 09 Aug '20

09 Aug '20

Boost release 1.74.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.74.0.beta.1/source/> The SHA256 checksums are as follows: 577a6b575ff2c227e14cce1b929c73d969475e58f3d2ab2901ad234f773bbd12 boost_1_74_0_b1.7z ba09c72dc848e7c0904922967014d853897b5a634926c910cc3b1fd627c31605 boost_1_74_0_b1.tar.bz2 2ccdc39efa076822cf1b359f9449f9d07707f3e27a18b393297b25885a9ff45b boost_1_74_0_b1.tar.gz c267c450166e040a374eaddab5e583cef09f6c3fe96a4db826172d0315c38dd5 boost_1_74_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_74_0.html>. Please download the beta, give it a try, and report any problems you encounter. Issues that were found during the beta release process and will be fixed for the final 1.74.0 release: * The Boost.STLInterfaces documentation was left out of the beta. * Some of the Boost.Geometry documentation files have very long names; this could cause problems on platforms (like Windows) with shorter limits on path lengths. * There is a compile error in Boost.ASIO when compiling with 32-bit MSVC-14.2 with BOOST_BEAST_NO_TS_EXECUTORS. Thanks, -- The Boost Release Team

2 3

[release] Master branch now closed for 1.74.0 release
by Marshall Clow 06 Aug '20

06 Aug '20

1 0

Re: [boost] Hello everybody, I have something to share about the shared_ptr class
by 逸霖杨 04 Aug '20

04 Aug '20

Last post was sent directly to Rob, I forgot to cc list.bost.org. Thinking of the multiple calling of the detors, which is suggested by Rob and other members, I came up with some ideas. This IS about specification. If class A has a dispose method like class A { A(){} ~A(){} //Dispose method: !A(){} }; Where !A() can be called multiple times and ~A() can be called only one time. Everything rcgc_ptr delegates will be called its dispose in !A() and therefore multiple times to just decrease the reference count and finally call ~A() when real delete happens. And this can be done on the compiler level (!A() maybe not visible at all or just visible when you use like ~A()). Saying this algorithm is a part of the C++ language itself, then C++ has no need to manually manage pointers (at least the unwanted management). Idea is inspired by all of you especially Andrey Janson and Rob. Thank you all! Best Regards, Yilin

3 10