August 2020 - Boost - lists.boost.org

[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