- Boost - lists.boost.org

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