April 2018 - Boost - lists.stage.boost.cppalliance.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 199

[RFC] unique_val (handles, IDs, descriptors...)
by Miguel Ojeda 15 Oct '18

15 Oct '18

Hi all, While working on a medium-sized project, I had to wrap quite some handles, IDs, descriptors, etc. into RAII classes. Somehow, writing those and making them movable seemed more verbose than needed. I searched in the STL and Boost for something already implemented, but nothing seemed to come up. I decided to write my own prototype to see whether I was missing something important; but actually using it in my project felt quite natural and simple. At this point, I asked for a second opinion from a well-known expert (thanks Scott!) and he agreed that it seemed like a reasonable idea but, of course, he would also be surprised if others haven't come up with something similar. So I polished it up a bit and uploaded it to: https://github.com/ojeda/unique_val Below you have the introduction inlined [1]. If you have the time, please take a look (specially to the Rationale) and let me know your comments. The code itself is very short and straightforward. If you already have this class/template in Boost somewhere that I missed, please let me know! Otherwise, if you think this could be interesting to put into Boost in some existing library (not sure which) or as a new tiny library, I would be glad to make the effort to expand it, clean it up, etc. Thank you! Miguel [1] """ A single-header header-only library for representing unique values (handles, IDs, descriptors...) that default to a value on move for C++11, C++14 and C++17. It simplifies writing resource-owning classes (RAII) with move semantics support for resources with handles, IDs or descriptors that are supposed to be used as unique values, not as unique pointers. For instance, it can be used with non-pointer handlers (like the `int` file/socket descriptors in POSIX) and with opaque pointer handlers (like the `HWND` handles in the Win32 API). As such, it can be used as an alternative to `std::unique_ptr` with or without custom deleter, specially for resources that use a non-pointer type or resources that are not simply heap-allocated. It does not have any overhead compared to using the original type. It supports booleans, integers, pointers and enumerations. The default value can be different than the default-constructed value (i.e. different than 0, nullptr, etc.). """

7 13

Original STL Library Documentation has been recovered and is now safe forever.
by Robert Ramey 02 Sep '18

02 Sep '18

The Standard Template Library is the foundation of modern C++. The creation and publication of this code and its documentation set a new standard for the formal specification of what a computer program should do, how it should be designed and how it should be formally documented. These pages were maintained first by Silicon Graphics and then later by Hewett-Packard. In January of 2018 these pages were removed by H-P. This is a historic blunder. I have recovered the original STL Library Document and hosted them here: http://www.rrsd.com/software_development/stl/index.htm Robert Ramey

8 10

[outcome] v2.1 progress report
by Niall Douglas 04 Jun '18

04 Jun '18

Dear Boost, Two months after you accepted Outcome into Boost, I am pleased to say that I believe that all the known bugs and very substantial source refactoring recommended by the peer review have been implemented (detailed changelog is appended below). What remains is a few months of maturing in real world use as all this severe refactoring needs to be tested outside a test suite, and of course the documentation which I don't intend to start work on until the autumn. The Boost edition has, obviously, received a major upgrade and it is now 100% "Boost native" in that it uses Boost.System and Boost.Exception now. The test suite for the Boost edition exclusively tests the Boost native edition, and it all passes. Outcome (both standalone and Boost editions) now can handle both Boost and std types freely intermixed as you see fit. A new "lite" single header edition exists which drags in virtually no system headers, and is hideously low impact on compile times as a result. ABI and API stability have been dumped to git repo with scripting to check the current library against the frozen dumps. This edition should make the corporate crowd very pleased. Very little should appear to have changed from the outside. Code written for v2.0 ought to, more or less, compile and work as before with v2.1. I would appreciate whatever help the Boost community can give in helping to test this edition. I expect new bugs to have been introduced given the severe source code refactoring, and new dual support for Boost and std as equals. My gratitude in advance. Niall --- ## v2.1 in progress [[project]](https://github.com/ned14/outcome/projects/1) - Boost edition is now 100% Boost, so defaults for `result` and `outcome` are `boost::system::error_code::errc_t` and `boost::exception_ptr`. Moreover, the test suite in the Boost edition now exclusively tests the Boost edition. One can, of course, freely use the standalone edition with Boost, and the Boost edition with `std` types. - Renamed ADL discovered customisation point `throw_as_system_error_with_payload()` to `outcome_throw_as_system_error_with_payload()`. - [#135](https://github.com/ned14/outcome/issues/135) - Added much clearer compile failure when user tries `result<T, T>` or `outcome` where two or more types are identical. Thanks to Andrzej Krzemieński for suggesting a technique which combines SFINAE correctness with the remaining ability for `result<T, T>` etc to be a valid type, but not constructible. - [#67](https://github.com/ned14/outcome/issues/67) - Fixed one of the oldest long open bugs in Outcome, that the noexcept unit tests failed on OS X for an unknown reason. - [#115](https://github.com/ned14/outcome/issues/115) - Outcome did not construct correctly from `failure_type`. - Inexplicably outcome's error + exception constructor had been removed. Nobody noticed during the Boost peer review, which is worrying seeing as that constructor is needed for one of the main advertised features to Boost! - [#107](https://github.com/ned14/outcome/issues/107) and [#116](https://github.com/ned14/outcome/issues/116) - `operator==` and `operator!=` now become disabled if the value, error and exception types do not implement the same operator. - Relatedly, both comparison operators simply didn't work right. Fixed. - [#109](https://github.com/ned14/outcome/issues/109) - `swap()` now has correct `noexcept` calculation and now correctly orders the swaps to be whichever is the throwing swap first. - Added reference dump of v2.1 ABI so we can check if ABI breakage detection works in the next set of changes, plus Travis job to check ABI and API compatibility per commit. - [#124](https://github.com/ned14/outcome/issues/124) - `OUTCOME_TRY` is now overloaded and selects `void` or `auto` edition according to input parameter count. - [#120](https://github.com/ned14/outcome/issues/120) - Fix generation of double underscored temporary variables in `OUTCOME_UNIQUE_NAME`, which is UB. - [#110](https://github.com/ned14/outcome/issues/110) - Separated `result` from its hard coded dependency on the `<system_error>` header. - Renamed `result` and `outcome` to `basic_result` and `basic_outcome`. - Renamed `result.hpp` into `basic_result.hpp`. - Moved `<system_error>` and `<exception>` dependent code into new `std_result.hpp` and `std_outcome.hpp` header files. - Added `boost_result.hpp` and `boost_outcome.hpp` which use Boost.System and Boost.Exception (these are `result.hpp` and `outcome.hpp` in the Boost edition). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 1

Proposal for a thread synchronisation primitive: future_queue
by Martin Hierholzer 21 May '18

21 May '18

Dear boost developers, I want to propose a thread synchronisation primitive, which works like a mixture of (lockfree) queues and futures. Therefore I gave it the name "future_queue". It is basically a lockfree queue which can be waited on for new values (without busy waiting), but it has some nice extra features like when_any() and continuations. The github project can be found here: https://github.com/mhier/future_queue It already contains a README file with a short description, an example and results of a first performance measurement. Further documentation so far exists only inside the code: https://github.com/mhier/future_queue/blob/master/include/future_queue.hpp My first question is, whether this is really something new (I might have overlooked something in the many boost libraries) and if it makes sense to integrate it into the boost libraries. Another question would be whether this should really be its own library, since it is basically a single class (with a few helper classes) and a single non-member function. Maybe it would be better to make it part of an existing library? I am happy to receive some first feedback! Cheers, Martin -- Martin Hierholzer DESY Notkestrasse 85 22607 Hamburg Office 55a / 123 Tel: +49 40 8998 1897 Mob: +49 176 992 46 476 Skype: mhier48 This e-mail may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you received it in error, please advise the sender immediately by reply e-mail and delete the original. Any further use - especially any form of publication - of this e-mail without explicit authorisation is strictly prohibited.

4 11

[type_traits] revisiting is_virtual_base_of
by John Maddock 10 May '18

10 May '18

There is a problem with is_virtual_base_of in that it doesn't work especially well - most of the time it works OK, but can be made to fail catastrophically in a few situations, see for example: https://svn.boost.org/trac10/ticket/11323 Now... it turns out that with C++14 and later we now have is_detected which can test the validity of almost any expression... and I'm wondering if there's a cunning way to press this into action to create a more accurate is_virtual_base_of, but I'm having trouble coming up with anything. Any bright ideas? Note that an explicit static_cast can't be tested for, though we can use is_constructible if required. Thanks in advance, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 3

[release][website] Help wanted
by Daniel James 01 May '18

01 May '18

Hello all, For the last couple of releases, I've been handling the releases mostly on my own, but I'm starting a new job and I'm going to have a lot less time, or maybe even no time, for Boost. So we really need more people helping with release management and updating the website. The main release manager responsibilities are described here: https://svn.boost.org/trac10/wiki/ReleasePractices/ManagerCheckList It's probably best if there are a few people involved. I don't think all of them will need admin permissions. For updating the website, you mainly need to occasionally edit html/quickbook files, accept pull requests to the release notes, and use the php scripts to updates the site at release time (I should be able to help a little there). thanks, Daniel

6 5

Showstopper: Build broken on predef module
by Vicente J. Botet Escriba 30 Apr '18

30 Apr '18

Hi Rene, I've needed -to update to the last boost version and I'm experimenting the same issue as the one reported in https://github.com/boostorg/build/issues/299 but in my Mac. /Users/viboes/github/m_boost/libs/predef/check/../tools/check/predef.jam:46: Unescaped special character in argument $(language)::$(expression) /Users/viboes/github/m_boost/tools/build/src/build/configure.jam:288: in try-find-build *** argument error * rule log-check-result ( result ) * called with: ( ) * missing argument result Do you have an idea of what is wrong? Best, Vicente

3 5

Need help with adding tests
by fady esam 30 Apr '18

30 Apr '18

Hi, i was working on a new opencl api for ublas and i need to add the tests and benchmarks to the ublas library. Amy help would be appreciated :) I am adding my file to the test-suite numeric/uBLAS but i want to add include directories and link 2 libraries with compiling the code.. Can anybody help me with that? Thanks in advance

1 0

[doc] Libraries Listed by C++ standard
by Mateusz Loskot 27 Apr '18

27 Apr '18

Hi, Since each Boost library seems/is free to decide about which C++ standard they require, would it be useful to start tagging each library with standard in the release notes and docs? Perhaps new "by by C++ standard" listing could be added in here https://www.boost.org/libs/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 8