July 2017 - Boost - lists.preview.boost.org

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

base64?
by Greger 16 Aug '17

16 Aug '17

Hi Is anyone interested in a base64 encode/decode library (for boost)? ty Greger

9 15

Posts not appearing on Boost Mailman
by Raffi Enficiaud 14 Aug '17

14 Aug '17

Hi Boost, I have an issue with MailMan: I never use "emails" for posting on the Boost ML, I use news.gmane.org through thunderbird. I can see my posts on news.gmane.org, but I cannot see any of my posts here for instance: https://lists.boost.org/Archives/boost/2017/07/index.php Is this normal? Thanks, Raffi

5 8

Switch to CMake -- Analysis
by Thomas Heller 12 Aug '17

12 Aug '17

Hi list, After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations... First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit? Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such. Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote: > [...] our build system has become an impediment for many developers > and users, existing and prospective. Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit. Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors. Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;) All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config). While your add it, improve Boost.Build, maybe it can rise again from its ashes (why did it "fail" in the first place?). Regards, Thomas

27 78

Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday
by Marshall Clow 02 Aug '17

02 Aug '17

Get your bug fixes and documentation updates in now! -- Mashall Upcoming release schedule: 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release

7 20

[outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0
by Niall Douglas 31 Jul '17

31 Jul '17

For boost-dev's information: https://www.reddit.com/r/cpp/comments/6qo1m3/outcome_v2_has_reached_stabili… --- cut -- I am pleased to announce that Outcome v2, rewritten to fulfil the Boost peer review feedback from May and only reaching feature completeness three weeks ago, has been successfully deployed into two complex libraries which were heavily using Outcome v1. Lots of bug fixes and maturity has resulted, and if you were holding off on deploying Outcome into your own code until now, now is the time! The code itself is now ready for a second Boost peer review, it has all the same testing that v1 had, and I am highly confident as to its quality. What solely remains before Outcome v2 can reenter the Boost peer review queue for a second review is the documentation which remains parlous (and any help with it is greatly appreciated!), and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission. I am also going to have to fix a number of bugs in Standardese the documentation tool first, it currently segfaults when fed the Outcome headers :). @foonathan's tool shows lots of promise, it does far better with C++ 17 than doxygen, just need to shave off some rough edges in the tool. What comes before that though is writing a WG21 paper P0762R0 summarising the Boost peer review which led to the stripped down, barebones v2 `result<T, E>` design and the rationale for the design deviations from `expected<T, E>` as according to the Boost peer review feedback. If WG21 feel warm feelings about a `std::result<T, E>` after reading P0762R0, then I will prepare a formal standardisation proposal for the Library Evolution Working Group (LEWG) and get the ball rolling for standardisation by attending meetings from 2018 onwards until it's through. I'll announce any draft D0762R0 here when it's ready for people to comment and give feedback on soon. My thanks to everyone here on Reddit, on boost-dev, on SG14 low latency, and privately who have helped out with testing, documentation, and so much more in making this library happen. I know those coming from Rust-land feel amazement how long it has taken C++ to replicate Rust's `Result<T, E>`, but I'm very sure ours is enormously superior to theirs already simply by doing so much less because it doesn't need to. Taking time to get design **right** is one of the big things which continues to separate C++ from the upstart systems programming languages. Long may it continue! --- context --- Outcome provides a C++ 14 STL-quality `result<T, EC>` and an `outcome<T, EC, E>` implementation of success|failure value transports, and is expected to pass a second Boost peer review and be submitted for C++ standardisation as the lowest level of an overall framework as proposed by: - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r0.pdf C++ Monadic interface - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r2.pdf A proposal to add a utility class to represent expected object (Revision 4) The idea is that result/outcome are the extremely lightweight struct-like success|failure value transports suitable for usage in public APIs, whereas expected is the much richer variant-like monadic success|failure value transports, and everything participates together under P0650R0. Outcome is a pure header only library with no dependencies. It works best with C++ 17 and Concepts enabled, but can work with C++ 14 on these compilers or better: - clang 4.0 (5.0 required for Windows) - GCC 7 (VS2017 Update 3 RTM is supposed to work too according to Microsoft, my thanks to them for swiftly fixing the several ICEs I reported) Github: https://github.com/ned14/outcome Docs (highly incomplete): https://ned14.github.io/outcome/ Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 4

Boost 1.65.0 Beta 1
by Marshall Clow 31 Jul '17

31 Jul '17

Boost release 1.65.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/> The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1.zip Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 8