April 2020 - Boost - lists.preview.boost.org

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

Optional library
by anshu khare 27 May '20

27 May '20

Hi mentors I was going through the optional library of boost. I was facing some problem in understanding the code base. In lines from 94 to 97 in optional.hpp, the code is as follows: struct in_place_init_if_t { Struct init_tag{}; explicit in_place_init_if_t(init_tag) {} //not able to understand this line }; I understand that we are creating a structure in_place_init_if_t and inside that we are creating another structure init_tag and then we are calling the constructor of in_place_init_if_t. But I am not able to understand that what does it the constructor do when we pass init_tag as an argument to it. Is it same as we are creating a structure Car and then creating another structure wheels inside it and passing wheels as an argument to the constructor of car as follows: struct car { Struct wheels{}; explicit car(wheels) {} //not able to understand this line }; Could you please tell what is the significance of passing wheels as an argument in this counter example?

2 1

[Filesystem] Directory entry caching
by Chris Glover 13 May '20

13 May '20

Hi All, Whatever happened to the work in this branch https://github.com/boostorg/filesystem/tree/feature/directory-entry-cache-r… that looks to implement this paper? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html Wondering if it's planned, dead, or looking for someone to do the work. I ran into the problem today by chance. -- chris

4 10

[Range] Transform in place
by Frederick Gotham 11 May '20

11 May '20

Earlier today I wrote the following two lines of code: auto const my_range = v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2); boost::range::transform( my_range, my_range.begin(), std::bit_not<uint8_t>() ); However it would have been nice as a one-liner: boost::range::transform( v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2), std::bit_not<uint8_t>() ); Why isn't there a form of "range::transform" that can transform in place (and therefore takes exactly two arguments)?

3 2

Embarcadero C++ and Boost libraries
by Edward Diener 01 May '20

01 May '20

Embarcardero ( formerly Codegear, formerly Borland ) has had for about five years C++ compilers based on clang, along with the venerable bcc32, which is the Borland compiler of old through a number of transformations. The clang-based Windows compilers are bcc32c/bcc32x for 32-bit development and bcc64 for 64-bit development. The only difference between bcc32c and bcc32x is that the former takes the same command line flags as their legacy bcc32 compiler while the latter, like bcc64, takes clang command line flags. The clang-based C++ compilers are based on clang-5.0, and use the Dinkumware library. The clang based compilers still predefine __BORLANDC__ and __CODEGEARC__ but also predefine __clang__. The latter is the way to distinguish in preprocessor code between the bcc32 compiler and the clang-based compilers. Despite numerous workarounds in Boost code based on the predefined macros __BORLANDC__ and __CODEGEARC__ the bcc32 compiler, not being very C++ compliant even at the C++98/C++03 level at which it operates, has not really worked for Boost since about Boost 1.39. It is useless for modern day Boost. Therefore I have made efforts, in contact with some Embarcadero C++ representatives, to integrate the clang-based compilers into Boost, especially since there is a free non-commercial offering by Embarcadero called C++ Builder Community Edition at https://www.embarcadero.com/products/cbuilder/starter which any Boost developer could use to test these compilers if they wished. I am doing this in the hopes that this may become effective for Boost 1.74.0. Doing this involves: 1) Creating an embarcadero.jam toolset, based on the clang-linux.jam toolset, which supports bcc32x and bcc64. Updating the borland.jam toolset to also support bcc32c. I have done these and the PR has been merged to 'develop' on Boost Build. 2) Updating Boost Config to support the clang-based compilers. I have done this and the PR has been merged to 'develop' on Boost Config. 3) In the update to Boost Config, I have created these macros: a) BOOST_BORLANDC = __BORLANDC__ with __clang__ not defined b) BOOST_CODEGEARC = __CODEGEARC__ with __clang__ not defined c) BOOST_EMBTC = Embarcadero C++ compilers with __clang__ defined Therefore what is really needed in Boost libraries is to change all the code which currently uses __BORLANDC__ to BOOST_BORLANDC and all the code which uses __CODEGEARC__ to BOOST_CODEGEARC when Boost config has been included. When in the rarer case that Boost config has not been included, then __BORLANDC__ logic becomes __BORLANDC__ and !__clang__ and __CODEGEARC__ logic becomes __CODEGEARC__ and !__clang__. I am workiog on doing this for the numerous Boost libraries with workarounds nased on __BORLANDC__ and __CODEGEARC__ in Boost code, and will create PRs for those libraries. I only ask that library maintainers will merge the PRs I create once they have passed their CI tests, since the PRs are almost all just simple transformations regarding the __BORLANDC__ and __CODEGEARC__ in the code. If any library maintainer wants to so this on their own in the 'develop' branch it would be appreciated. Further points: The Embarcadero C++ clang-based compilers are not as good as clang itself, which is at release 9, gcc, or vc++. But they are good enough for the majority of Boost code. The Embarcadero C++ clang-based compilers support only C++17. The documentation implies that they also support C++11 and C++14 but that is not so. But since Boost libraries written for a C++ standard level are supposed to work flawlessly at a higher level this is no impediment for C++ Builder programmers using the Embarcadero C++ compilers in current Boost. I have reported a number of bugs, based on my Boost testing, for the Embarcadero C++ compilers to Embarcadero themselves in their bug reporting system. I believe that any registered user of their free community edition can report bugs to Embarcadero C++ at their bug reporting system at https://quality.embarcadero.com. Hopefully these reports will improve the compilers. It would really be nice, once the Embarcadero C++ clang-based compilers are integrated into current Boost, if regression testers could test their compilers. I will try to do so myself if I have the time and resources. I have discussed this with some Embarcadero C++ representatives about adding the Embarcadero clang-based C++ compilers to one or more CI testing services, but currently there are not any which support them of which I know. Besides the clang-based Windows compiler Embarcadero also has clang-based C++ compilers for 32-bit and 64-bit iOS ( Apple ) and for Android ( Google ). The code in Boost Config distinguishes between these environments, if necessary, with further macros based off of the mnemonic BOOST_EMBTC. It would be nice to add these configurations to embarcadero.jam once the rest of the work is done. But I have no idea how to test any of these other compilers as they are not part of the Windows based Embarcardero C++ Builder Community Edition.

2 4

Re: [boost] [review][STLInterfaces] STLInterfaces review results (ready for merge)
by Barrett Adair 30 Apr '20

30 Apr '20

On Thu, Dec 26, 2019 at 2:31 AM Barrett Adair <barrettellisadair(a)gmail.com> wrote: > > Many thanks are owed to all who participated in the formal review of Zach Laine's STLInterfaces library, especially during this busy holiday season: > > * Hadriel Kaplan - ACCEPT > * Andreas Wass - ACCEPT > * Rainer Deyke - ACCEPT > * Arthur Gruzauskas - ACCEPT > * Krystian Stasiowski - ACCEPT > * Daniela Engert - CONDITIONALLY ACCEPT > * Gavin Lambert - Technical comments > > (snip) > > The reviews clearly demonstrate a consensus. Accordingly, I'm pleased to announce that STLInterfaces is CONDITIONALLY ACCEPTED as a Boost library. > > Conditions for acceptance: > 1. Remove optional dependency on cmcstl2 (issue #27) > 2. Add Boost license comments to all files, including appveyor.yml, .travis.yml, README.md, */CMakeLists.txt (issue #26) > 3. Support Boost.Build (issue #25) > 4. Replace googletest with Boost equivalent (issue #24) > 5. Remove usage of non-existent v2_dtl members in container_interface.hpp (issue #22) > 6. Include <tuple> for std::tie usage in C++14 mode (issue #21) > 7. Fix dangling parens in container_inteface.hpp:731 (issue #20) > 8. Make Concepts usage C++20-conformant (issue #13) > 9. Remove the destructor in container_interface (issue #12) > 10. Add tests for non-copyable value types (issue #30) > > (snip) I've confirmed that STLInterfaces (https://github.com/tzlaine/stl_interfaces) has met the conditions for acceptance. Review wizards, please reply with any objections. Merge ticket here: https://github.com/boostorg/admin/issues/174 Thanks, Barrett

4 5

GSoC 2020 proposal review and GSoD
by Tom Kwok 29 Apr '20

29 Apr '20

Hi David (and other potential mentors), I updated my repository hosting my little project of C++ matrix classes for the GSoC competency test. Also, is there any editing needed for my proposal? I am sure you and other mentors are busy reviewing so I am sorry for bothering you with this message. If I don’t receive further feedback I would take it as no changes are needed (yet). Also, I read that Boost community is interested in participating GSoD (Google Season of Docs) as well. I would like to express my interest in GSoD participation and I look forward to hearing updates on specific requirements on GSoD participants and/or projects that Boost community may have. Best regards, Tom > On 23 Apr 2020, at 3:51 PM, boost-request(a)lists.boost.org <mailto:boost-request@lists.boost.org> wrote: > > Message: 8 > Date: Thu, 23 Apr 2020 08:25:22 +1000 > From: David Bellot <david.bellot(a)gmail.com <mailto:david.bellot@gmail.com>> > To: Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>>, Boost users list > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > Subject: [boost] 10 slots for the Google Summer of Code 2020 > Message-ID: > <CAOE6ZJGh_rM_Dg=h8SYktYoMqux2g+eAt7FiTaShJSs9UkeVMA(a)mail.gmail.com <mailto:CAOE6ZJGh_rM_Dg=h8SYktYoMqux2g+eAt7FiTaShJSs9UkeVMA@mail.gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > Hi Boost community, > > this year Google allocated 10 slots for the Google Summer of Code. It's > again a great achievement thanks to the hard work of our team of dedicated > mentors. > > We are now selecting the best students among all the proposals we receive. > We received 79 proposals this year. 10 of them will be selected. > > This year, a lot of proposals if not all are targeting a finalization of > the work which has been done in the previous GSoCs and we should see a lot > of code being pushed in production. It's a very exciting time for all of us. > > The mentors are now hard at work to choose the students. We'll keep you > informed when it's official. > > Best regards, > David

2 1

[release] Boost 1.73.0 Release Candidate 1
by Marshall Clow 28 Apr '20

28 Apr '20

The first release candidates for the 1.73.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.73.0/source/> The SHA256 checksums are as follows: d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_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

9 22

Emails from Travis CI not coming?
by Andrey Semashev 28 Apr '20

28 Apr '20

Hi, Does anyone else have a problem with build result notifications from Travis CI not coming? I haven't received emails from Travis for about a month, although I can see the completed builds in the web UI. I checked spam, they aren't there.

2 4

CI Testing and failures
by Edward Diener 28 Apr '20

28 Apr '20

Sometimes CI testing fails because of a bug in a compiler. It is possible to designate in a jam file that a particular test should not be done for a particular compiler version so that CI testing succeeds, and therefore a PR can be more easily merged because the CI tests "succeed". But then the fact that the compiler has a bug is masked by such a change to the jam file. Is there a solution to such a problem, or maybe this is really not a problem at all ? What do others think about this ?

2 3

[release] 1.74.0 open for merging
by Marshall Clow 28 Apr '20

28 Apr '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 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

[release] Boost 1.73.0
by Marshall Clow 28 Apr '20

28 Apr '20

Release 1.73.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 2 new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.73.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.73.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, Micheal Caisse and Glen Fernandes

1 0

Controlling _BOOST_CMAKEDIR in installed .cmake files
by Jonathan Wakely 24 Apr '20

24 Apr '20

With Peter Dimov's help I've resolved my earlier problems packaging Boost for Fedora. Now my problem is that the generated .cmake files contain the full --prefix path, which is not what I want because that's just a staging area, not the final resting place for the files (think DESTDIR in an autotools build). I see lines like this in each of the installed .cmake files: /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake:if(EXISTS "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake") /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake: get_filename_component(_BOOST_CMAKEDIR_ORIGINAL "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake" REALPATH) /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake: set(_BOOST_CMAKEDIR "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake") These files won't work after everything gets moved from the staging area $RPM_BUILD_ROOT/usr/... to the final lcoation on a user's machine, under /usr/... I can just use sed to alter them, but surely there's way to set the desired prefix? I'm trying: ./bootstrap.sh --with-toolset=gcc --with-icu --prefix=/usr ./b2 -d+2 -q -j 4 \ --without-mpi --without-graph_parallel --build-dir=serial \ --prefix=/usr --libdir=/usr/lib64 \ variant=release threading=multi debug-symbols=on pch=off \ python=3.8 \ stage ... ./b2 -d+2 -q -j 4 \ --without-mpi --without-graph_parallel --build-dir=serial \ --prefix=$RPM_BUILD_ROOT/usr \ --libdir=$RPM_BUILD_ROOT/usr/lib64 \ variant=release threading=multi debug-symbols=on pch=off \ python=%{python3_version} \ install And this produces the .cmake files with the unwanted $RPM_BUILD_ROOT/usr prefixes. I originally didn't have the --prefix and --libdir options on the bootstrap.sh command and the 'b2 .. . stage' command, but it doesn't seem to matter whether they're there or not. Is there some way to control the prefix that ends up in those .cmake files?

2 2

Google Season of Docs
by David Bellot 24 Apr '20

24 Apr '20

Hi, The registration for organization is now open. If anyone is interested in managing this project and wish to talk about now, please let me know. I've got some experience now managing the Google Summer of Code and can help with GSoD too. Cheers, David

13 46

[thread] Determinig the thread API
by Edward Diener 23 Apr '20

23 Apr '20

What determines whether the Boost thread library is built with pthreads or win32 thread support if the threadapi feature is not specified when building the library ?

2 2

[release] Master branch now closed for 1.73.0 release
by Marshall Clow 23 Apr '20

23 Apr '20

1 0

10 slots for the Google Summer of Code 2020
by David Bellot 22 Apr '20

22 Apr '20

Hi Boost community, this year Google allocated 10 slots for the Google Summer of Code. It's again a great achievement thanks to the hard work of our team of dedicated mentors. We are now selecting the best students among all the proposals we receive. We received 79 proposals this year. 10 of them will be selected. This year, a lot of proposals if not all are targeting a finalization of the work which has been done in the previous GSoCs and we should see a lot of code being pushed in production. It's a very exciting time for all of us. The mentors are now hard at work to choose the students. We'll keep you informed when it's official. Best regards, David

1 0

[release] 1.73.0 post-beta merges
by Marshall Clow 22 Apr '20

22 Apr '20

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on April 22nd. -- The release managers

8 13

MySQL ASIO library
by Ruben Perez 22 Apr '20

22 Apr '20

Hi all, I have been writing an ASIO-based client for MySQL, trying to mimic what Beast is to HTTP. It currently supports SQL queries and prepared statements. It can be viewed here: https://github.com/anarthal/mysql-asio Do you guys think this has the potential to be useful or become part of Boost long term? Any feedback is very welcome. Thanks, Ruben (Anarthal).

6 12

[release] Reminders - Master branch closes for 1.73.0 release TOMORROW
by Marshall Clow 21 Apr '20

21 Apr '20

And don't forget to update your release notes! -- Marshall

2 1

[build][b2] Add colors support to echo rule and actions
by Mateusz Loskot 21 Apr '20

21 Apr '20

Hi, I did an experimental UI/UX wank for B2: https://github.com/boostorg/build/pull/573 If anyone is interested in this kind of thing, then let's make B2 great again! ;) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[geometry] Boost 1.73 beta docs include broken links to Geometry Extensions
by Mateusz Loskot 19 Apr '20

19 Apr '20

Hi, I asked about it here a while ago, but without responses [1] https://lists.boost.org/Archives/boost/2020/03/248531.php We have been observing this problem since 1.70 and we have pretty much run out of ideas what is wrong with Boost.Geometry setup [2] https://github.com/boostorg/geometry/issues/585#issuecomment-605106308 The issue is still observed in the 1.73 beta docs [3] https://github.com/boostorg/geometry/issues/585#issuecomment-614263295 Could anyone help us understand [2] what is the problem with our docs? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Wrong boost.173-beta1 tag for boost.test
by Raffi Enficiaud 18 Apr '20

18 Apr '20

Hi, I just noticed that the tag "boost-1.73-beta1" points to e8b173655c207ec2286227fe17f2e1f68ce44f17 in boost.test, while master points to 9a8cdba280a9c5dc60c4781a26e055ebfe2446ea, and the content of the boost_1_73_0_b1_rc1.tar.bz2 archive is the same as master. I am expecting that the tag "boost-1.73-beta1" points to the content of the archive boost_1_73_0_b1_rc1 . Raffi

2 1

Git documentation is full of twisty passages
by Jonathan Wakely 17 Apr '20

17 Apr '20

I've once again got lost trying to find how to check out Boost from Git. I started at boost.org and (after some missteps) went to https://www.boost.org/users/download/#repository which tells me "Details of the git repositories are on the Boost wiki." https://svn.boost.org/trac/boost/wiki/ModularBoost That takes me to a page with about 20 links. Eventually I decided that the 13th one is the one I want: Getting Started with Modular Boost https://svn.boost.org/trac10/wiki/TryModBoost That takes me to a page that says: "This page is superseded by https://github.com/boostorg/boost/wiki/Getting-Started Please help migrate the rest of the old wiki !" But when I go to that page it says: "The Boost Wiki is at: https://github.com/boostorg/wiki/wiki" So I go there instead, which has nothing about Git. The "Getting Started" page has a link to "Getting Started with Modular Boost Library Development using Git" right at the very bottom, and the "Getting Started - Using Git" link in the sidebar takes me to a different page with very generic Git info (not specific to Boost), and again, near the bottom, is the "Getting Started with Modular Boost Library Development using Git" link. So I click that and ... I'm back in Trac, at https://svn.boost.org/trac10/wiki/StartModWorkflow I don't care bout Boost's use of Git Flow. I don't care about your branching policy, I want to check out the repo! It turns out that on the front page of https://github.com/boostorg/wiki/wiki I should have clicked the "Cheat Sheet" link in the sidebar: https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Cheat-Sheet Could you please make that easier to find from boost.org? It seems to me that https://www.boost.org/users/download/#repository should just link straight to that cheat sheet, or to another page with the correct git submodule commands for checking out the repo.

2 3

Fwd: teeks / boost.test: some test files not found
by Raffi Enficiaud 16 Apr '20

16 Apr '20

I am cross-posting this on the dev mailing list as I would like to know how to fix this before the 1.73 deadline. Thanks and sorry for cross-posting, Raffi -------- Forwarded Message from the test gmane group Hi, On some teeks workers, I have this strange issue: teeks99-09-p-64: https://www.boost.org/development/tests/develop/developer/output/teeks99-09… The error says: .../libs/test/test/framework-ts/log-formatter-test.cpp(117): error: in "test_logs": check output.match_pattern(true) has failed: Pattern file can't be opened! which means some files used for testing, such as test/test/baseline-outputs/log-formatter-test.pattern , are not found. Those files are advertised in the Jamfile, https://github.com/boostorg/test/blob/develop/test/Jamfile.v2#L145 I guess it would be a hard error on b2 if the files were not found. What should I do such that those workers find the test files? I recently added one file to the previous 2 existing files. Thanks, Raffi

1 0