- Boost - lists.preview.boost.org

[review][mp11] Review of Mp11
by Glen Fernandes 23 Jul '17

23 Jul '17

What follows is my review of the Mp11 library: [Should the library be accepted into Boost?] Yes. I vote for an unconditional ACCEPT. [What is your evaluation of the design?] Excellent. The design where any template can serve as a list, and any template can serve as a meta-function is both elegant and powerful. The additional quoted meta-function support with utilities such as mp_bind, mp_bind_front, and mp_bind_back, addresses the other request I had when reviewing an earlier version of Mp11. While HOMF were never essential, as the article pointed out, users appreciate more ways to one-line things without having to write a helper type. Some additional primitives are desired, as mentioned later in this review (e.g. min and max functionality) but overall the toolkit is already vast and useful. [What is your evaluation of the implementation? Excellent. The focus on performance is definitely appreciated while we still have to depend on libraries for many of these meta-programming primitives. Ideally many of these would be provided in the standard library and have implementations that only a compiler vendor could provide with built in support, and offer performance beyond what a library could offer. In the meanwhile, the performance offered by Mp11 is great, more than sufficient for my needs, and in my opinion also for the majority of users. In comparison, the tiny C++11 meta-programming library that I have implemented, uses only the obvious C++11 implementations for most functionality, and does not offer the same fast compile times as the equivalents in Mp11. The techniques used by Mp11 via C++11 constexpr, C++14 constexpr, and even C++17 fold expressions, besides improving Mp11 performance, were a valuable source to learn from. Suggestion: Can all the workarounds for MSVC versions 1800 and older for the empty list cases be avoided by instead using a helper trait? i.e. template<template<class...> class L, class... T, template<class...> class P> struct mp_find_if_impl<L<T...>, P> { using type = typename mp_find_if_impl_2<P, T...>::type; }; i.e. Introduce mp_find_if_impl_2 which would then have the obvious implementation as before, only without requiring the MSVC workaround? This is only worth considering if you find it to offer some benefit such as: Additional maintainability of the Mp11 code, with less workarounds, and no costs, e.g. no increase in compilation times as a consequence. [What is your evaluation of the documentation? Very good. The reference documentation is clear, and easily understood. More example and tutorial content before the reference section would always be welcome, but not necessary. Suggestion: The two-part article that Peter wrote (which is referenced in the documentation) is in my opinion so valuable for users to gain better understanding and appreciation of the library that it should be included in the library distribution as part of the documentation. Ideally in the same Asciidoc form as the current documentation, as a supplemental document (or Appendix entry). Suggestion: Does it make sense for the documentation to have a section describing the conventions the library uses, for potential contributors as much as users? e.g. If someone was designing an mp_min_element, should it yield the element type result, or the list index size constant result? Is there an established convention of when an error is acceptable for an empty list versus returning an index? Correction: Under heading mp_find_if<L, P>: "mp_find_f<L, P> is an" should be "mp_find_if<L, P> is an". [What is your evaluation of the potential usefulness of the library? Incredibly useful in its current form, and this is only going to increase as the library is extended based on user requests for additional functionality. Almost every meta-programming primitive that I have needed recently either already exists in Mp11, or I am able to implement using Mp11 with a little effort. During this review I replaced the use of my own meta-programming library in a project of mine without any issues. As part of this review I also tried several exercises where I implemented certain traits and meta-functions using Mp11. Of all the exercises that I attempted, the only one where the library lacked the necessary utility was an "mp_min_element" function: This was an implementation of the typical "type_with_alignment" trait, which can easily be implemented using a "min_element" functionality. Mp11 does not have mp_min, mp_max, mp_min_element, mp_max_element presently, and I believe they should be added because they are useful and users will probably find themselves implementing it. Sure, mp_sort exists, but I would not use a sort when a min_element can suffice. In this case, type_with_alignment<N> could use mp_min_element with a predicate that finds the type in an mp_list of several scalar types, that matches has an alignment of at least N and has the smallest size, and then check that the result element type of the mp_min_element is at least N. The litmus test for me for a meta-programming library is the question: Would I use Mp11 in library code? The answer for me is "yes". If it was part of Boost, I would use it in other Boost libraries (that already require C++11 or higher). [Did you try to use the library? With which compiler(s)? Did you have any problems?] Yes. I used the library as a replacement for an existing meta-programming library of mine in real (non-toy, non-exercise) project code that is compiled with g++ 4.8.5 in c++11 mode for x86 and x86_64 Linux, using Boost 1.64.0, on 64-bit RHEL 6 and measured compilation times. I also used the library in a few exercises that I compiled with g++ 7.1 and clang 4.0.0, for x86 and x86_64 Linux, using the current Boost master branch, for c++11 and c++14, on 64-bit Fedora 26, and again measured compilation times. I also compiled and ran the Mp11 unit tests with the compilers, C++ standard modes, architectures, Boost distributions, and operating systems mentioned. [How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?] More than ten hours over this weekend reading the documentation, reviewing the implementation and tests, using Mp11 in a project replacing my own C++11 meta-programming library, using it in various exercises, and running the Mp11 unit tests with the various compilers, C++ standard modes, targets, and Boost distributions listed above. Prior to the preparation for the review, I had spent some time with an earlier version of Mp11 and comparing it to Metal for implementing a few meta-functions, including the "instantiates_" example from my library: instantiates_<T, templates_<std::set, std::multiset, std::unordered_set> > Where instantiates_ should be implemented in terms of "is_instantiation_of_": is_instantiation_of_<T, std::set> Which has the obvious behavior indicated by the trait name. The Mp11 approach provided by Peter for this case, and the relative ease with which I was able to implement the other meta-functions using Mp11 were a convincing demonstration of the usefulness of the library. [Are you knowledgeable about the problem domain?] Like many of us, I had written a meta-programming library as C++11 language features have become available. Before that, if Boost.MPL solved a problem, more often than not it was convenient and useful enough to just use it, even if writing my own implementation would result in faster compilation times. Peter's article, however, opened my eyes to a more elegant design, and changed how I implemented my C++11 meta-programming library, and in general shaped what I think about meta-programming in modern C++. Thank you Peter for your work on Mp11, for submitting it for inclusion in Boost, and for the articles that motivated it and taught the rest of us. Glen

1 0

[reflection] Which if any reflection library to use
by RAM 22 Jul '17

22 Jul '17

I'm working on code that will need to use reflection, and would like to know if boost already has a reflection library, or uses one preferred library? I know there are future C++ proposals such as those listed below, and am curious if any of them have already been implemented somewhere? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0590r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0385r2.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0194r2.html

4 5

Re: [boost] CMake Announcement from Boost Steering Committee
by Brian Wood 22 Jul '17

22 Jul '17

Klemens Morgenstern writes: >Am 21.07.2017 um 22:50 schrieb Niall Douglas via Boost: > >> Some would say that what has been achieved so far is a pale shadow of >> what would have been achieved without the self-serving elitism. If you >> look at the bits of Boost which got into the C++ standard, they are very >> obviously the simple bits. There's a lesson in that. > Let's see: > > Without templates > - boost.system_error > - boost.error_code > - boost.thread > - boost.filesystem > > With type erasure: > - boost.any > - boost.function > > With templates: > - boost.SmartPtr > - boost.variant > - boost.optional > - boost.bind > - boost.tuple > > Template black magic: > - boost.type_traits > - boost.asio (probably as the networking TS) > - boost.EnableIf > > May I ask what you based your statement on? Did you even look at the > list or would actually checking facts be elitism? I think you have to "chew the meat and spit the bones" (*) when it comes to Boost and the standard. And you left out the best one imo -- array. String_view is a good one also. On the other hand, I avoid std::any and I'm skeptical about filesystem. I make conservative use of unique_ptr and try to avoid shared_ptr. (*) My rabbi in Austin, Texas used to say this -- not in relation to Boost though. Brian Ebenezer Enterprises http://webEbenezer.net

1 0

boostorg now no longer a fork of har999y. [Fwd: Severing a 'fork' connection]
by Glen Fernandes 22 Jul '17

22 Jul '17

No longer related to har999y in any boostorg repositories. Glen ---------- Forwarded message ---------- From: Antonio Diaz (GitHub Staff) <support(a)github.com> Date: Fri, Jul 21, 2017 at 9:54 PM Subject: Re: Severing a 'fork' connection To: Glen Fernandes <glen.fernandes(a)gmail.com> Hey Glen, Thanks for that approval! I've detached that fork for you. Please let me know if you need anything else. Cheers, Antonio GitHub Support

2 1

Re: [boost] [review][mp11] Reminder of ongoing formal review
by Jason Rice 22 Jul '17

22 Jul '17

Hello, my name is Jason Rice, and this is my first Boost review so please take that into consideration. I'm also new to this mailing list thing so let me know if I did something wrong here. Please consider the following review for the proposed Boost.Mp11 library: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. ACCEPT. No conditions 2. What is your evaluation of the design? The interface is very straight forward. It is mostly templates but the user is not burdened with accessing a nested "type" with every metafunction. The list algorithms are flexible in that they take any kind of list which is very handy. I did notice that the user is burdened with ensuring that a list is not const or they will just get a "implicit instantiation of undefined template" error which doesn't really point to the problem. (e.g. when using mp_append with many lists) The `mp_` prefix is welcome if this is destined for the `std` namespace. The `tuple_apply` could probably just be called `apply` since appears to be a shim of `std::apply`. The interface of map functions accepting any list of list is very nice. 3. What is your evaluation of the implementation? The implementation is very clean. I looked at `mp_map_find_impl` and it is very concise and easy to understand. I did find it annoying though that some of the public facing functions are defined inside detail files which makes the source code a little more difficult to traverse. I'd like to see mp_product perform on par with the other libs on metaben.ch 4. What is your evaluation of the documentation? For the interface, it gets the job done. The table of contents has some text wrapping that could be fixed. There is no instructions for installation that I could find anywhere. It fails to mention that Boost.Config is a dependency. (AFAICT) 5. What is your evaluation of the potential usefulness of the library? I use Boost.Hana quite a bit. I'm currently using a library like this to help where optimization for compile-time performance is needed so it is definitely useful. 6. Did you try to use the library? With what compiler? Did you have any problems? I used it in my library Nbdl to augment my use of Boost.Hana in a couple of places. The compiler is a recent pull of the Emscripten fork of clang targeting X86. I did get stuck for a while on a weird error I mentioned before because a used a const list. I didn't like having to also install Boost.Config. (I'm not using the Boost monolith build) 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a few hours on it. I used mp_append and mp_with_index in my lib with great results. I just looked at the implementation of mp_map_find. I scoured the documentation looking for stuff and seeing what else was available. 8. Are you knowledgeable about the problem domain? Yes, I have done TMP and I am also a contributor to Boost.Hana. Jason Rice

2 1

Are there libraries without ACTIVE maintainers?
by Alexander Zaitsev 22 Jul '17

22 Jul '17

Hello. I think it's very important question: are there libraries without ACTIVE maintainers? For what? Because without active maintainers we can't guarantee quality of the libraries. Is Boost community sure, that for all Boost libraries there are active maintainers? E.g. see on Boost.Property_tree - on Github repo you can find a lot of "dead" pull requests without any answer. What should we do with it?

11 14

Re: [boost] Switch to CMake -- Analysis
by Rene Rivera 22 Jul '17

22 Jul '17

On Jul 22, 2017 4:41 AM, "Peter Dimov via Boost" <boost(a)lists.boost.org> wrote: Tim Blechmann wrote: fwiw, cmake and b2 have different architecture as one is a build system the > other is a generator for build systems. > I wonder how many of the people who repeat this mantra understand either Boost.Build or CMake. CMake does not generate build _systems_, it generates build _scripts_. So does, incidentally, Boost.Build, which is a major reason why it's so hard to understand. It would be more accurate to say that cmake generates build "scripts". And B2 generates build "instructions" (since it's internal data structure management).

2 1

Moving CMake forward
by John Maddock 22 Jul '17

22 Jul '17

Man but there's been a lot of hot air expanded on this subject.... guys if we're going to do this, just do it. We're empiricists around here: lets see what the proponents of CMake can come up with, yes I know there are straw man proposals, but I want something that demonstrates it can fully handle the complex cases at least as well as Boost.Build, and be maintainable by CMake ignorants like myself, because lets face it, once the transition is over, library authors will have to do the maintenance grunt work as before: and if we can't easily see how to do that, then the project probably fails. As a minimal first step, what I would like to see come up for review (yes a review folks!) is a system that: * Provides users with a way to build those libraries with source via CMake. All of them together, or just some subset. * Provides an install option for all of Boost. * Is trivially easy for non-CMakers like myself to maintain. Documentation should be provided (Boost/CMake best practice is...). * Is fully compatible with current auto-linking naming on Windows (plus whatever else comes along later like address-model and architecture name mangling that's in the works and has long been requested). * Supports libraries with non-trivial build requirements (regex, locale, what others?). * Is usable by end users to be able to easily reference Boost libraries from their own CMake projects (note, might be limited to libraries with source, since header only libraries are kind of trivial). An example, and how to documentation should be provided. * It would be nice if generated VS projects were reference-able from our own solutions as well, but I accept that may not be possible. * Is at a minimum, no worse than what we have now. What else? Takers? BTW, I don't see a need for this to encompass every Boost library with source before some kind of mini-review to iron out the warts... Just hoping to move things along, John. --- This email has been checked for viruses by AVG. http://www.avg.com

5 7

Re: [boost] Switch to CMake -- Analysis
by Thomas Heller 21 Jul '17

21 Jul '17

Am 21.07.2017 6:42 nachm. schrieb "Vinnie Falco via Boost" < boost(a)lists.boost.org>: On Fri, Jul 21, 2017 at 9:34 AM, Stefan Seefeld via Boost <boost(a)lists.boost.org> wrote: > Then *please* let's not add unrelated points to the discussion, for the > sake of getting a handle of what problems we have to solve, and how. Hmm...my apologies but I think this error is very much on-topic: >CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762 (message): >Imported targets not available for Boost version It's a symptom of the problem. It is off topic in the regard that insisting that the problem exists won't make it go away. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

1 0

[review][beast] Beast Review Results
by Michael Caisse 21 Jul '17

21 Jul '17

In an effort to get you all to just read this announcement sequentially, I will start with the result: Beast is ACCEPTED into Boost without conditions The entire community is served when the Boost review process works well and I would like to personally thank each of you who took your valuable time and worked to make Boost better. We had 21 formal reviews submitted from a demographic that included both seasoned participants and first-time reviewers. It is gratifying to have such participation for what some might see as a niche library. * Thank you Vinnie for your effort to assemble a high-quality package for review and for your responsiveness on the mail-lists. GitHub, and Slack. * Thank you to the individuals that submitted their first Boost review. * Thank you to the veteran contributors and authors for continuing to devote energy to the community. I found the discussion surrounding the library beneficial and I know that Vinnie walked away with actionable items to improve Beast. -------------------- The Stats: -------------------- While the review process is not exactly tallying up votes and casting a verdict, we can gain some insight of the general, gross-scale opinion of the library. Official reviews were received from: Reviewer Accept | Reject ------------------------------------------ * Zach Laine : X * Nik Bougalis : X * Artyom Beilis : X * Peter Dimov : X * Klemens Morgenstern : X * Glen Fernades : X * Marcel Ebmer : X * Scott Determan : X * Stanislav Karchebnyy : X * Michael Larson : X * Vadim Zeitlin : X * Jared Wyles : X * Niall Douglas : X * Barrett Adair : X * Gyorgy Szekely : X * Daniela Engert : X * Jens Weller : X * Phil Endecott : X * Bjorn Reese : X * Rüdiger Berlich : X * Christopher Kohlhoff : X Most of the reviewers agreed on the inclusion of Beast into Boost and at the same time that Beast isn't a great name for the library. (Just say Boost.Beast 10-times-fast). Vinnie has a FAQ item discussing the name and his continuing use is deliberate. He has heard the petitions to change and weighed them. -------------------- Concerns: -------------------- A variety of concerns and comments were made during the review. An impressive number of items were addressed in code or documentation during the review period itself. Some of the stated concern for rejection included: * Too many templates * Run-time polymorphism / OO would be better. * Library scope is too small and provides no real value to users - This is clearly one of those value judgements and for some users the not-in-scope nature of Beast made the feature set not compelling enough to use or have as a Boost library. Other users spent time converting existing projects to use Beast. This included projects previously running POCO, libcurl, and homegrown solutions. Beast has existing commercial and open-source users. The library clearly meets the needs of some users. * Premature optimization * Security concerns * Poor support for HTTP chunking - Vinnie proposed and then later made changes addressing the chunking concerns. Unfortunately, the reviewer with the complaint did not respond to multiple requests for feedback. * Licensing - Four files have dual licenses (BSL and another). Boost's legal counsel is reviewing the situation and we hope to have guidance by the end of this week. I have not placed a condition on the acceptance of Beast based on the legal feedback because Vinnie knows licensing issues must be remedied before the repository is merged into Boost. -------------------- The Upsides: -------------------- There were lots of great things said about the Beast package. Some of these include: * Great documentation * High quality implementation. * Thorough test suites * Already being used by commercial entities and others * Lots of successful real-life conversions of existing clients/servers * Extremely responsive developer (do you sleep Vinnie?) -------------------- An Author as much as a Library: -------------------- Accepting a library into Boost is also accepting an author. Boost authors have enormous latitude in the control and modifications of their libraries. Vinnie has shown dedication to addressing issues, listening to constructive input, making changes when appropriate, and protecting his vision of what the Beast is. I believe Vinnie will serve the community well as a contributor. -------------------- Final Thoughts: -------------------- Reviews are hard. It is hard to have your work torn apart and remain considerate. It is hard to repeat answers to previously asked questions. It is hard to explain specific use-cases and why it is important a library supports them. It is difficult to critique a large body of work. It is hard to stick with conversations to make overall improvements. I was impressed with the participants in the review. We are all opinionated and passionate -- likely a prerequisite to being part of the Boost community. Thank you all for making Boost better. I'm looking forward to seeing additional libraries and application built with Beast. -- Michael Caisse Ciere Consulting ciere.com

6 10

[OFF] Inclusive language (Was: [review][beast] Review of Beast starts today : July 1 - July 10)
by Vinícius dos Santos Oliveira 21 Jul '17

21 Jul '17

2017-07-01 21:54 GMT+02:00 Vinnie Falco via Boost <boost(a)lists.boost.org>: > Such language is non-inclusive and diminishes the stature of the list > (in my opinion). So what? What's the problem of non inclusive languages? This is just automatic reaction. Rust language community is full of this shit and is unbearable. “but-but-but the feelings... oppression”. Grow up. If you're on the Rust community, you cannot criticize design decisions that anyone will answer with “you have a very negative tone indeed”. That community is cancer (oh... I just used an oppressive word... how unpleasant I'm looking now...). And it's the same community which will **applaud** a guy who says shit about async I/O... like... “I think the proper way to use async I/O is creating threads”. The same fucker who says “I don't like Windows... that's why I don't support Windows”. As a matter of fact, I don't like Windows either, but I leave my non-important programming tastes out of my working environment (so oppressive). Next time you will want to ban blacklist/whitelist from your repos because that's racist. Stop this fucking nonsensical bullshit. You end up hiding yourself behind a prepared excuse. The only part I agree with you is the part on keeping the topic focused. That's why I'm creating another topic just for that. Niall's comment was absolutely on topic as a critique of the obvious. He could just say in other words, like “you're not programming seriously if you ignore error handling”. Or he could be so desperately concerned about politically correct. It'd be a great and unnecessary distraction. He would start to censor himself and not say everything which may be of value because he is scary of “improper language”. He didn't even need to censor himself this time (you've done this for him — a community of self-vigilant sheep... how wonderful will be our future... just like Rust and its “nazi-demographic surveys/corrections-to-be-done”). Do not mirror Rust's bad practices here. Do as Niall and try to mirror the good parts instead (e.g. error handling). Feel free to only answer after review of Beast finishes. Otherwise I'll steal focus that shouldn't be stolen now. Actually, I suggest to only answer after the review period finishes. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 10

Strawman proposals for CMake support
by Louis Dionne 21 Jul '17

21 Jul '17

Hi, I'd like to expose two strawman proposals for adding CMake support to Boost. Both proposals would solve the following problems, with different advantages and disadvantages: (1) Users have a hard time integrating Boost into their build system, which is CMake more often than not. (2) Prospective Boost developers are sometimes driven away from submitting because they would have to learn Boost.Build, which is not widely used and has a limited knowledge base. FIRST PROPOSAL ============== The first proposal is to move completely to CMake and to render Boost.Build support optional. The possible rollout plan would look something like: 1. We start requiring that new libraries support both Boost.Build and CMake. 2. We start adding CMake support to existing libraries. This will take time. 2.1 We start moving our infrastructure to be CMake-based. 3. We release Boost with dual support for a while, letting time for things to bake. 4. We remove the requirement that Boot libraries can be built with B2. Libraries (existing and new ones) are free to provide such support, but they are not required to. This would bring CMake to the status of "primary" build system for Boost. This could be based on Paul Fultz's work in progress at [1]. This has the following advantages (in the long term): - Less technical debt because we only have one "official" build system to maintain. - The build system is uniform across all of Boost, which means it's easier for folks to maintain it and understand it. - It gives maximal flexibility to CMake-based users. However, it has the following drawbacks: - We'll need to do a wholesale migration to build system XYZ when CMake is not cool anymore. - It's harder to get buy-in from some developers that love Boost.Build SECOND PROPOSAL =============== The second proposal is to make Boost into an almost build-system agnostic collection of libraries. Basically, 1. Provide CMake package config files for all Boost libraries so that they can be used from CMake (either automatically, manually, or a mixture of both). This could be based on Peter Dimov's work at [2] (or [3], not sure which one is most current). 2. Make it possible to build CMake-based projects from Boost.Build, or the other way around, or provide a build system agnostic script to build all of Boost. This way, Boost libraries can decide whether they want to support B2 or CMake. This has the following advantages: - Possibly easier to implement - We could possibly support other build systems too (e.g. if a Boost author really wants to use scons for his/her library) - We don't have to do a wholesale move to XYZ when CMake is not cool anymore I see the following disadvantages: - Boost's infrastructure could grow more complex as a result - Our build system would be less uniform - We would have to depend on all the build systems that we want Boost libraries to be usable with My personal preference is towards the first option, since I think it would be simpler in the long term. I could certainly be convinced otherwise. There are probably other ways we can solve problems (1) and (2) exposed above. There are also certainly advantages and disadvantages that I forgot to mention above. I'd love to get some feedback on those two approaches and see whether one of them (or something else completely) can get some consensus on this list. Cheers, Louis [1]: https://github.com/boost-cmake/bcm [2]: https://github.com/pdimov/boost-cmake-demo-2 [3]: https://github.com/pdimov/boost-cmake-demo -- View this message in context: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 9

A vision of Boost
by David Sankel 21 Jul '17

21 Jul '17

I got involved with Boost in 1999. I was 17, attempting to learn C++, and saw a footnote in "The C++ Standard Library" that mentioned boost.org as a place where quality C++ libraries are found. For me, it was love at first sight. Automatic pointers? Amazing. 'std::array'? Fantastic. I've been using C++ and Boost ever since. Never in my wildest dreams would I have imagined that eighteen years later I'd be sitting on the C++ standardization and Boost steering committees. As I listen in the Library Evolution Working Group I imagine what it must've been like for Beman and Dave to sit in similar meetings and ask themselves "wouldn't it be great if there were an online place that collects freely available C++ libraries and offers a peer-review process for incorporation? It'd be hugely beneficial for C++ users and the C++ standard as well." People get involved in Boost for many reasons. Some think it'll improve the chances they get their library standardized (and it's true!). Some think it'll improve their consulting or job prospects (true as well!). Others hone in on particular aspects, such as the build system, the people, or individual libraries. All these reasons are great, but for me the key was Boost's mission: to improve the way people code. At first it was more about improving the way I code, but as time went on it became more and more about helping others. For me, this is something worthwhile; worth sacrificing for. Now there are pros and cons with moving Boost to CMake, but at the center of all steering committee discussions has been the Boost mission. "How is this going to help us reach more users?" "How is this going to help us reach more developers?" "How is this going to impact the standard and the greater C++ community?" We may have made the wrong choice (though I doubt it). We may have communicated it in a non-ideal way. However, one thing is for sure: We made the decision based on furthering Boost's mission. A mission I want others to fall in love with like I have. So, we're moving to CMake. And, yes, we'll get there together. Many questions still exist and we'll have to figure out the answers as a community. The stalemate, however, is now over. -- David Sankel

2 1

[outcome v2] ntkernel_category() custom error category appropriate for Outcome?
by Niall Douglas 21 Jul '17

21 Jul '17

I put together a custom `std::error_category` for NT kernel `NTSTATUS` error codes with error condition comparison support for both POSIX and Win32 error code spaces: https://github.com/ned14/ntkernel-error-category Question: Is this custom `std::error_category` so niche and unlikely to be useful to anybody that people would object to it being supplied in Outcome v2? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Greetings everyone!
by Arnav Karmarkar 21 Jul '17

21 Jul '17

Hello, I'm Arnav. I came across Boost when going through the list of organisations that take part in GSoC. I found Boost very interesting, so can anyone guide me with how to proceed? Thanks!

2 1

[BB++] Now is 3.5x faster than Node.JS
by Phil Bouchard 21 Jul '17

21 Jul '17

Greetings, I am now using C++14 standards, the error reporting is all compile-time now and I get a test that is 3.5 faster than Node.JS! You can see it by yourselves here: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp Furthermore there is no need for 'operator ->' anymore because the access operator is deduced at compile-time. Here is a code sample: int main() { int temporary = 1; auto foo = function () { return function (int argument) { return argument; }; }; for (int i = 0; i < 1000000; ++ i) cout << foo()(temporary) << endl; } Note that it's also possible to dynamically allocate function pointers like this: int main() { int temporary = 1; auto foo = new function () { return new function (int argument) { return argument; }; }; for (int i = 0; i < 1000000; ++ i) cout << foo()(temporary) << endl; } I will show you a clear example of cyclic references handling soon. Regards, -Phil http://bbplusplus.com/

1 0

boost no longer builds mpi libraries when using intel mpi
by Franck Houssen 20 Jul '17

20 Jul '17

Hello, Just to get your attention to this : https://github.com/easybuilders/easybuild-easyconfigs/issues/1065 Franck

4 13

MS controlled email domains - not going to work
by Michael Caisse 20 Jul '17

20 Jul '17

The irony in sending this message is that the people who need to see it probably wont get it. We are having trouble with hotmail.com, live.com, msn.com, and outlook.com. Microsoft is filtering the dedicated IP address used by the mail lists and most recently has responded with: Not qualified for mitigation [ip address] Our investigation has determined that the above IP(s) do not qualify for mitigation. These IP(s) have previously received mitigations from deliverability support, and have failed to maintain patterns within our guidelines, so they are ineligible for additional mitigation at this time. We have tried to explain multiple times that the IP address has a new owner but we seem to be stuck in almost an auto-response loop. We will continue to try and get service unblocked; however, I would recommend that you dump your MS controlled accounts for Boost mail lists and use another service. michael -- Michael Caisse Ciere Consulting ciere.com

2 1

Re: [boost] CMake announcement timing
by Bjorn Reese 19 Jul '17

19 Jul '17

On 07/19/2017 06:03 PM, Edward Diener via Boost wrote: > I think it is very unfair to make the announcement regarding Boost and > CMake while a review is ongoing. Surely the announcement could have > waited until after the review period for mp11. I raised this point with Jon yesterday in my role as review manager. The situation is difficult to handle now that the announcement has been made, other than to ask people to show temperance for the duration of the review, which ends next Monday (July 24th.)

1 0

CMake announcement timing
by Edward Diener 19 Jul '17

19 Jul '17

I think it is very unfair to make the announcement regarding Boost and CMake while a review is ongoing. Surely the announcement could have waited until after the review period for mp11.

3 2

Introducing the Backbone++ Programming Language
by Phil Bouchard 19 Jul '17

19 Jul '17

Hello Boost, (The former language name is already taken by Microsoft) By taking advantage of the simplicity of the code of Javascript, the power of C++ and the deterministic C++ memory manager Root.Ptr, I decided to write my own programming language which takes advantage of all these powerful features. On the downside Javascript suffers from a slow garbage collector that kicks in randomly which makes it impossible to write real-time engines and C++ just doesn't have any objective memory manager up to this day. My initial attempt was to convert Javascript into C++ but then the principle of 'closures' and 'escape analysis' inlaid with Javascript just makes it impossible to get rid of the garbage collector. So if we sacrifice these principles away then we can integrate Root.Ptr and take advantage of the power of C++ and the true flexibility and run-time features of Javascript. It has to be noted that BB++ is an extension of C++ and therefore everything we can do in C++ can also be done in BB++ and vice-versa. You can find the source code here: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp And the benchmarks indicate BB++ is 3 times faster than Node.JS! Note that the language is still in a preliminary state but we can already compare it. Furthermore, in theory, it should be possible to offer a service which compiles the executables for combinations of major architecture / OS only once, cache these executables on the webserver and executing them in a specialized container on the client's desktop. This or convert the file BB++ -> C++ -> WebAssembly. Thus, in theory, we would be able to execute real-time engines from within our own browser! So I am including Boost because the backend of BB++ is Root.Ptr and the benefits are inevitable at this point. You can see here an example of mixing BB++ with C++ code and how easy it is for the language to get rid of cyclic references: https://github.com/philippeb8/root_ptr/blob/bb++/bbpp2cpp/tests/input2.bb Regards, -Phil http://www.fornux.com http://www.finitetheory.com https://www.actatabula.com http://www.backbonepp.com

2 2

Free e-book on Packt: Git: Version Control for Everyone by Ravishankar Somasundaram
by degski 19 Jul '17

19 Jul '17

To any-one interested. As per the title <https://www.packtpub.com/application-development/git-version-control-everyo…> (Registration (free) required). Have a *good* day, degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 0

[math] Efficient polynomial multiplication
by Lakshay Garg 18 Jul '17

18 Jul '17

Hello all This is my first post to the mailing list. While looking at the source code for polynomial multiplication (boost/math/tools/polynomial.hpp) I discovered that the library used O(N^2) algorithm for multiplication. I would like to work on implementing a more efficient algorithm (complexity: O(N log(N))). I am writing this mail to get views and feedback from the community and have a healthy discussion before starting the work. Lakshay

5 8

Introducing the X++ Programming Language
by Phil Bouchard 18 Jul '17

18 Jul '17

Hello Boost / Qt, By taking advantage of the simplicity of the code of Javascript, the power of C++ and the deterministic C++ memory manager Root.Ptr, I decided to write my own programming language which takes advantage of all these powerful features. On the downside Javascript suffers from a slow garbage collector that kicks in randomly which makes it impossible to write real-time engines and C++ just doesn't have any objective memory manager up to this day. My initial attempt was to convert Javascript into C++ but then the principle of 'closures' and 'escape analysis' inlaid with Javascript just makes it impossible to get rid of the garbage collector. So if we sacrifice these principles away then we can integrate Root.Ptr and take advantage of the power of C++ and the true flexibility and run-time features of Javascript. It has to be noted that X++ is an extension of C++ and therefore everything we can do in C++ can also be done in X++. You can find the source code here: https://github.com/philippeb8/root_ptr/tree/x++/xpp2cpp And the benchmarks indicate X++ is 2.7 faster than Node.JS! Note that the language is still in a preliminary state but we can already compare it. Furthermore, in theory, is should be possible to offer a service which compiles the executables for combinations of major architecture / OS only once, cache these executables on the webserver and executing them in a specialized container on the client's desktop. Thus, in theory, we would be able to execute real-time engines from within our own browser! So I am including Boost because one day X++ could be merged with the C++ programming language and I know Boost is well used in the vast gaming industry which requires real-time engines. Regards, -Phil http://www.fornux.com http://www.finitetheory.com https://www.actatabula.com https://github.com/philippeb8/root_ptr/tree/x++/xpp2cpp

3 7

Error handling libraries and proposals
by Emil Dotchevski 17 Jul '17

17 Jul '17

Last week it was brought to my attention that there are currently 5 different libraries and proposals for dealing with the problem of reporting errors from noexcept functions, so I thought it would be useful to update the Noexcept documentation with a short section comparing all the different designs: https://zajo.github.io/boost-noexcept/#alternatives.

6 43

Re: [boost] Outcome v2
by Groke, Paul 17 Jul '17

17 Jul '17

> From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37 > To: boost(a)lists.boost.org > > Ah, now I get it, thanks for the explanation. There *might* even be a > way to get this to work even without memory allocation in the end > (without exception_ptr), but I think this is perhaps missing the point > of returning an error object, which is to be able to interact with it. > Also, reasonably if you could fit the things you need to create the > object into a "small object optimized" buffer, you can probably fit the > object itself into the same buffer. Noexcept already has that, it's the > result<T> object, however it might be too heavy to return up the call > chain one level at a time (it is instead designed for capturing the TLS- > stored object to postpone its handling, perhaps after moving it to > another thread). The question is: how do you interact with a return value of unknown type? For exceptions it's much easier. There is at least the common practice to derive your exception from std::exception, so if nothing else, you can at least get an error message. And you can catch base classes, which can also come in quite handy.

3 2

Boost libraries and Travis CI
by Edward Diener 16 Jul '17

16 Jul '17

Evidently to turn on Travis CI testing for a Boost library in Github you need to be the Administrator for that library, and not just a team member for that library. Is an Admin request the way to get Travis CI testing turned on for a library ? If not what is the proper way to turn on Travis CI testing for a Boost library once the .travis.yml file is added to the library ?

2 1

Regression tests on 'develop'
by Edward Diener 16 Jul '17

16 Jul '17

A number of regression tests on 'develop' have not been run for a long time. These includes Linux tests by 'Sandia' and 'teeks'. Does anyone know why these regression tests have not run for quite a while ?

1 0

Preprocessor directive for a sequence that differs only in datatype
by Rishabh Arora 16 Jul '17

16 Jul '17

Hello Everyone, I was trying to use the boost.preprocessor to write some code which otherwise needs to be written for all the cases. Here's the code: https://github.com/BoostGSoC17/dataframe/blob/master/include/df.cpp (line no. 430 and 431). But on compilation it gives the error: error: macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given print_column <BOOST_PP_SEQ_ELEM(type, INNER_TYPE) >(i); I didn't understand the reason as when I wrote: print_column <BOOST_PP_SEQ_ELEM(any_numerical_value(0, 1, ...), INNER_TYPE) >(i); it works fine. Can anyone help me understand the error or provide an alternative way to do the same thing? Thanks in advance, Best Regards, Rishabh

3 6

[stacktrace][1.65 beta1] Problem with reference docs
by Joaquin M López Muñoz 16 Jul '17

16 Jul '17

The following http://www.boost.org/doc/libs/1_65_0_beta1/doc/html/reference.html displays BoostBook-related garbage rather than the real reference for the lib, unlike http://boostorg.github.io/stacktrace/reference.html Best, Joaquín M López Muñoz

4 5

[review][beast] Late review
by Christopher Kohlhoff 16 Jul '17

16 Jul '17

I realise this is quite late, but Vinnie asked for my opinion, so I asked for special dispensation from the review manager. Hopefully that is ok! In a nutshell, I think Beast should be accepted. Background: Although I may have some use for websockets in the future, my use case right now requires only HTTP (sorry Vinnie!). The use case involves incorporating HTTP protocol support into network applications whose primary purpose is something otherwise unrelated to HTTP. HTTP is used to support monitoring, configuration, and debugging facilities. Unlike typical HTTP use, the protocol is implemented not just over TCP sockets but also over local (UNIX domain) sockets. It is essential that the HTTP implementation minimises runtime overhead to avoid negatively impacting the quality of service for the other protocols. - What is your evaluation of the design? Overall the design is good. The library seems to be structured into several layers: 1. low level stateful parsers and serializers 2. operations to send/receive partial messages (*_some operations) 3. operations to send/receive header 4. operations to send/receive complete messages, using parser/serializer supplied by me 5. operations to send/receive complete messages This is a good thing, because it lets me select the appropriate layer for a particular use case. Whichever of layers 2 - 4 I choose, the best thing is that they all follow the same model for asynchronous operations as in Asio. All four of those layers work with arbitrary Asio streams, which was a requirement of my use case. This made using the library seamless, easily replacing my otherwise quick and dirty HTTP encoding and decoding approaches. The benefit of course is that someone else is taking care of ensuring the messages are well-formed, and doing a much better job of it. Layer 5 is good for simplicity and clarity. Based on my benchmarking, layer 4 seems to be the sweet spot for performance sensitive use cases, as it gives sufficient control of the placement of the "transient" objects used by the asynchronous operations. I use HTTP/1.0 almost exclusively, and one reason for this is that HTTP/1.0 allows the response to be sent without a Content-Length, with the end of content delimited by stream closure. One use for this is an infinite stream of data (e.g. monitoring output). Another use case is the ability to use the file descriptor as stdout for a child process. In both these cases, layer 3 fits the bill where I can send just the response header, and then take over the socket for my own needs. As for layer 2, the documentation for these functions still refers in places to a return value (or additional size_t argument to the completion handler), which is no longer in the code: synchronous read_some has a void return and async_read_some has a void(error_code) handler. Although this is probably vestigial documentation, actually I would prefer it if these lower level operations *did* return something, like the number of bytes transferred in the operation. This would assist in detecting badly behaved or pathological clients (like ones doing everything one byte at a time), and this is probably the main reason I would consider using the layer 2 operations. I haven't yet needed layer 1, but I can imagine how it might be used in transport agnostic code. I guess my main point is that by supplying all these layers, Beast is both powerful and flexible, and meets pretty much all of my likely needs. The body/reader/writer design feels a little awkward, and it seems like there is a more elegant design struggling to get out. However, my primary reason for looking at implementing a custom body was to support serving static files. As Vinnie now plans to include file support in the library itself, I have little reason to work directly with body/reader/writer directly any longer. Consequently, I am less concerned about the design here. However, I'd encourage Vinnie to keep exploring this. On a related note, once file body was added I was pleased to see how straightforward it was to incorporate platform-specific file transmission (TransmitFile, sendfile, etc) in a way that was transparent to the library user. There are some minor inconsistencies in template parameters, e.g.: parser has Allocator where serializer has Fields. I would have expected some symmetry here. The library includes reimplementations of a number of facilities from the networking TS. However, now the TS is done I plan to update Boost.Asio to match. If Beast is accepted then hopefully by the time it is incorporated, it will no longer need to include these at all. I'm not a huge fan of the library including typedefs for names from other boost libraries as part of the documented public interface, e.g. beast::error_code, beast::string_view. However, if it is to retain these, I'd at least like to see them given their own section in the documentation quick reference to make it clear that they are just aliases for external functionality. (Note: I'm just fine with the aliases themselves as a convenience for the library implementer.) - What is your evaluation of the implementation? The implementation is high quality. I do wonder about the implementation approach taken in the basic_fields storage. It uses a set, which is great asymptotically, but does mean allocation of a lot of small objects. In my experience (and in a totally unscientific survey of commonly used websites) the number of headers is usually small -- a dozen or two. In addition, when constructing or decoding a message, one would normally construct the set of fields in one go. Deletion of a field seems like it would be rare. Thus I wonder whether basic_fields could use a storage strategy geared towards the common case, e.g. a single storage blob for the fields themselves (vector<char>) plus an index (vector<size_t> of offsets to each field's beginning) for quick iteration. I don't think this would impact the API, so it's not essential. - What is your evaluation of the documentation? The documentation appears to be comprehensive. As mentioned above I did spot a few stray things that seemed to be left over from previous design iterations. There's also the occasional incomplete specification, e.g. basic_fields::at doesn't way what it does with multiple fields. Probably best to just raise these as issues. - What is your evaluation of the potential usefulness of the library? Very useful. It fits very well with my use cases. - Did you try to use the library? With which compiler(s)? Did you have any problems? Using gcc 6.1 on linux, I spent some time writing and rewriting several small http servers to evaluate the library, and Vinnie has now incorporated some of these into the beast repository as examples. Along the way I did discover some minor opportunities for improvement in the library, and Vinnie was quick to respond. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent many hours examining the library over a period of a few weeks, both before and during the review period. I gave the implementation and examples in-depth study, less so the documentation. - Are you knowledgeable about the problem domain? I hope Vinnie asked me to review Beast because I know a thing or two. However, I must qualify that: my experience in HTTP is almost entirely 1.0 and I only have a passing knowledge of websockets. Many thanks to Vinnie for creating Beast and proposing it for inclusion in boost. It is nice to see the addition of protocol implementations that build on top of Asio's asynchronous model so seamlessly. Cheers, Chris

1 0

Re: [boost] [Boost-users] Boost 1.65.0 Beta 1 [boost.python] issue
by Rene Rivera 15 Jul '17

15 Jul '17

On Fri, Jul 14, 2017 at 7:23 AM, Raffi Enficiaud via Boost-users < boost-users(a)lists.boost.org> wrote: > As I said in a previous post, I cannot get boost.python to build on > Windows: the target is just ignored (see stack trace below). > Missed that post :-( > I think there is a bug in .\tools\build\src\tools\python.jam A highly probable statement all on its own :-) > concerning the version computation: the variable "major-minor" is not set > properly if "version" is optional. > > In this block: > > ============= ("rule configure") > if $(version) > { > if ! $(version) in [ feature.values python ] > { > feature.extend python : $(version) ; > py$(major-minor[1])-version ?= $(version) ; > ============= > > The variable "major-minor" is empty. > > The "if" in the following block prevents from computing major-minor as > "version" is optional and is not set: > > ============= > local major-minor ; > if $(version) > { > major-minor = [ split-version $(version) ] ; > version = $(major-minor:J=.) ; > } > ============= > > I believe this can be fixed by recomputing "major-minor" in this block, > after "version" has been inferred. > > ============= > if $(cmd) > { > debug-message ...requested configuration matched! ; > > exec-prefix = $(sys.exec_prefix) ; > > compute-default-paths $(target-os) : $(sys.version) : > $(sys.prefix) : $(sys.exec_prefix) ; > > version = $(sys.version) ; > interpreter-cmd ?= $(cmd) ; > cmds-to-try = ; # All done. > } > ============= > Seems reasonable.. Can you put up a PR for that? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

Re: [boost] [fiber] PR: Replace #include "Windows.h" by "windows.h"
by Frédéric Bron 14 Jul '17

14 Jul '17

>> I have just checked and both mingw and mingw-w64 have only fully lower >> case >> headers. I just checked all includes files from boost (1.65.0 beta2) that have upper case character in their names and are present in mingw or mingw-w64 in lower case. Here is what I found: 3 files, Activation.h, Memory.h, Windows.h. Those are in the following files: ./libs/thread/src/win32/thread.cpp:36:#include <Activation.h> ./libs/iostreams/test/windows_pipe_test.cpp:9:#include <Windows.h> ./libs/process/test/bind_stderr.cpp:32:# include <Windows.h> ./libs/process/test/bind_stdin.cpp:34:# include <Windows.h> ./libs/process/test/sparring_partner.cpp:31:# include <Windows.h> ./libs/process/test/bind_stdout_stderr.cpp:30:# include <Windows.h> ./libs/process/test/exit_code.cpp:21:# include <Windows.h> ./libs/process/test/bind_stdout.cpp:32:# include <Windows.h> ./libs/process/test/group.cpp:32:# include <Windows.h> ./libs/process/test/spawn.cpp:33:# include <Windows.h> ./libs/process/test/spawn_fail.cpp:29:# include <Windows.h> ./libs/process/test/system_test1.cpp:38:# include <Windows.h> ./tools/build/src/engine/boehm_gc/MacOS.c:19:#include <Memory.h> ./boost/fiber/detail/futex.hpp:21:#include <Windows.h> ./boost/fiber/detail/cpu_relax.hpp:19:# include <Windows.h> So that is not a lot. For Memory.h, it seems related to MacOS, not Windows. If people really want to keep the upper case letter, we could then have #ifdef __MINGW32__ #include "windows.h" #else #include "Windows.h" #endif Frédéric Frédéric

1 0

[beast] Version 80: code review opportunity
by Vinnie Falco 14 Jul '17

14 Jul '17

Beast version 80 is sitting in the pull request queue if anyone is interested in providing a code review. This contains changes motivated by Bjorne's desire for more control over chunk-encoded output. <https://github.com/vinniefalco/Beast/pull/641> List of changes since beginning of the formal review: -------------------------------------------------------------------------------- * Javadoc tidying * Add basic_dynamic_body.hpp * Shrink buffer_prefix_view * Remove unused file_path * Add basic_file_body.hpp * buffers_ref is Assignable * Shrink chunk header buffer sequence size * Refactor chunked-encoding serialization * Remove spurious fallthrough guidance * Add span * Documentation work * Use make_unique_noinit * Fix warning in zlib * Header file tidying * Tidy up FieldsReader doc * Add Boost.Locale utf8 benchmark comparison * Tidy up dstream for existing Boost versions * Tidy up file_posix unused variable * Fix warning in root ca declaration * Tidy up basic_string_body * Add vector_body * span, string, vector bodies are public * Fix spurious uninitialized warning * fields temp string uses allocator * Add message::keep_alive() * Add message::chunked() and message::content_length() * Remove string_view_body * file_posix works without large file support * Always go through write_some * Use Boost.Config * BodyReader may construct from a non-const message * Add serializer::get * Add serializer::chunked * Serializer members are not const * serializing file_body is not const * Add file_body_win32 * Fix parse illegal characters in obs-fold * Disable SSE4.2 optimizations * Rename to serializer::keep_alive * BodyReader, BodyWriter use two-phase init * Use file_body for valid requests, string_body otherwise. * Construct buffer_prefix_view in-place * Shrink serializer buffers using buffers_ref * Tidy up BEAST_NO_BIG_VARIANTS * Shrink serializer buffers using buffers_ref * Add serializer::limit * file_body tests * Using SSE4.2 intrinsics in basic_parser if available * Add file_stdio and File concept * Add file_win32 * Add file_body * Remove common/file_body.hpp * Add file_posix * Fix Beast include directories for cmake targets * remove redundant flush() from example * Jamroot tweak * Verify certificates in SSL clients * Adjust benchmarks * Initialize local variable in basic_parser * Fixes for gcc-4.8 * basic_parser optimizations * Add basic_parser tests * Refactor header and message constructors * serializer::next replaces serializer::get * Tidy up set payload in http-server-fast * Refine Body::size specification * Newly constructed responses have a 200 OK result * Refactor file_body for best practices * Add http-server-threaded example * Documentation tidying * Various improvements to http_server_fast.cpp * Add websocket-server-async example * Fix extra ; warning * Documentation revision * Fix spurious on_chunk invocation * Call prepare_payload in HTTP example * Check trailers in test * Fix buffer overflow handling for string_body and mutable_body * Concept check in basic_dynamic_body * Tidy up http_sync_port error check * Tidy up Jamroot /permissive- * Fine tune websocket op asserts * Refactor websocket composed ops * Allow close, ping, and write to happen concurrently * Fix race in websocket read op * Fix websocket write op * Add cmake options for examples and tests * Return `std::size_t` from `Body::writer::put` Thanks

3 4

Re: [boost] [fiber] PR: Replace #include "Windows.h" by "windows.h"
by Frédéric Bron 14 Jul '17

14 Jul '17

>> Maybe we could use lower case windows.h only if __MINGW32__ is defined? > > It's still a fudge that might break. Isn't it better to get to the bottom of > the (MinGW-)problem (other headers are affected as well, as Windows.h is not > the only header starting with a capital)? That's right, we could look at all #includes in boost. I have just checked and both mingw and mingw-w64 have only fully lower case headers. Frédéric

1 0

[beast] Formal review
by Bjorn Reese 14 Jul '17

14 Jul '17

I am going to focus exclusively on the HTTP API in the review below because that needs most attention. Furthermore, to keep this review within reasonable bounds, I am omitting issues already reported by others. I. DESIGN --------- Beast offers a well-designed WebSocket API along with a minimal and deficient HTTP API. Beast claims to offer low-level building-blocks that can be used to produce higher-level HTTP server and client libraries. The low-level approach makes Beast minimal. I do not have a problem with a minimal API, other than it diminishes the usefulness of the library. Although this can be solved by adding more functionality over time, if I was to evaluate Beast with its current feature-level, I would only choose it if I needed WebSocket. This, however, is not a precondition for library acceptance. But the low-level approach also means the abstractions must be right. The abstractions that Beast currently offers are deficient, which is best shown by the poor support for HTTP chunking. Chunking can and should be represented more naturally by a HTTP API. HTTP chunking splits a message into several parts, where each part can contain metadata (chunk extensions) and data (chunk.) The metadata is a set of key-value pairs, just like the HTTP headers. During the review period I have described several use cases for HTTP chunking that does require metadata (e.g. radio metadata,) as well as the preservation of chunk boundaries (e.g. event-based publish-subscribe channels.) Conceptually, a normal HTTP message has the following structure: message = start-line metadata* body? A chunked HTTP message can be described in a similar manner as: message = start-line metadata* ( metadata* chunk? )* The Beast message container is designed for the structure of the normal HTTP message, and assumes that chunks are appended the body. The chunk metadata does not fit into this model, and therefore Beast discards them by default. The repetitive structure of chunked messages is not accommodated by the Beast message container. This means that we have to make our own chunk decorator to generate chunk metadata, and our own custom parser to receive chunk metadata. The chunk decorator inserts metadata via a callback mechanism. Its design is poor for two reasons. First, the user must keep track of context to ensure that the correct metadata is applied to the correct chunks. Second, the user must write the metadata in correct HTTP syntax. The latter may sound trivial, but does anybody here know if " ;key=value\r\n" is correctly formatted? (notice the initial whitespace.) The answer is that it is correct according to RFC 2616, incorrect according to RFC 7230, and correct according to RFC 7230 errata. The best approach for handling this situation is to never insert whitespaces, but to always accept whitespaces from others. Users should not have to be bothered with such detail. Receiving chunk metadata rather than having them discarded by default requires a custom parser. The Beast message parser is a push parser (SAX) where callbacks are invoked for each parsed message part. This means that the user must keep track of which metadata belongs to which chunk. The user must also parse the metadata manually. Beast does not even check if the syntax is correct. The custom parser is also necessary if the user needs to receive individual chunks rather than having them appended to the body. I would have expected that a low-level API returns the next message part as soon as it is identified. The current collect-entire-message design is a higher-level design. In summary, 1. Beast should not discard anything by default, but should faithfully forward all information received. 2. Beast should handle all low-level syntax and not leave parts of it to the user. 3. Beast should not break the end-to-end principle unless allowed by the user. As a way forward I am going to sketch another simple message model that does encompass HTTP chunking. Conceptually it looks like this (I am going to ignore that, say, metadata may require different syntax depending on context) message = start-line section* section = metadata* body-part? Building an API around this model should offer read/write functions that handles partial bodies (whether chunked or progressively downloaded.) The current collect-entire-message API could be build on top of that. With this approach there is no need to mess around with custom parsers. This design does require state information to be able to select the proper syntax for both metadata and data. On another topic, the HTTP status codes can be roughly categorized as instructions (the 1xx and 2xx series) and errors (the 4xx and 5xx series.) I recommend that you create two error categories and pass status codes as error_code. Notice that I have no comment about whether or not they should be stored in the message container. What I really want to achieve is to enable the user to easily propagate HTTP errors in the same way that non-HTTP errors (including beast::http::error) are propagated. II. IMPLEMENTATION ------------------ I read the implementation to understand the design, so I did not look for QA issues. My overall impression is that much of the code is well-written, but there are parts that are convoluted and difficult to verify. There are too many goto statements for my taste; I do not mind the goto pattern used in the parser, but the state-machines in read_some_op and serializer looks more like micro-optimization. Furthermore, "case do_body + 1:" looks like an awful hack. The dynamic buffers are useful even by themselves. The code contains several foreign files with different licensing conditions: * include/beast/core/detail/base64.hpp * include/beast/zlib/zlib.hpp * include/beast/websocket/detail/utf8_checker.hpp * include/beast/http/detail/basic_parser.hpp All these include both the BSL and the original license. This should be checked by the Boost legal council. III. DOCUMENTATION ------------------ The documentation is generally well-written (and it looks like the DynamicBuffer section got a little help from Networking TS.) The Reference is missing some concepts, e.g. SyncReadStream. IV. NAMING ---------- The library name must change. "Boost.Beast" sounds like a bad joke. I do not have strong opinions about the new name. V. VERDICT ---------- I recommend to REJECT the library because the HTTP API provides the wrong low-level abstractions as explained in the design section above.

12 46

Follow-up to the follow-up of the CMake follow-up
by Peter Dimov 13 Jul '17

13 Jul '17

In branch feature/install-cmake-config-2 of the superproject, you can find an improved version of the award-winning work presented in my previous follow-up. This one integrates into the top-level "b2 install" and "b2 stage" and installs (or, respectively, stages) the CMake configuration files necessary for find_package to work. The instructions for trying it out are the same as last time: git clone --recursive --depth 64 -b feature/install-cmake-config-2 https://githib.com/boostorg/boost bootstrap b2 headers b2 install then add the installation prefix to CMAKE_PREFIX_PATH. An example CMakeLists.txt could look like this: cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) list(APPEND CMAKE_PREFIX_PATH C:/Boost) find_package(boost_filesystem 1.63.0 REQUIRED) find_package(boost_program_options 1.63.0 REQUIRED) # disable autolink add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::filesystem boost::program_options)

4 8

[review][beast] Review of Beast starts today : July 1 - July 10
by Michael Caisse 13 Jul '17

13 Jul '17

The formal review of Vinnie Falco’s Beast library will take place from July 1 through July 10, 2017. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocol vocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. Beast is designed for: * Symmetry: Algorithms are role-agnostic; build clients, servers, or both. * Ease of Use: Boost.Asio users will immediately understand Beast. * Flexibility: Users make the important decisions such as buffer or thread management. * Performance: Build applications handling thousands of connections or more. * Basis for Further Abstraction: Components are well-suited for building upon. A branch has been made for the review. You can find Beast for review at these links: * Documentation : <http://vinniefalco.github.io/stage/beast/review/> * Source code : <https://github.com/vinniefalco/Beast/tree/review> * The FAQ answers real questions that come up : <http://vinniefalco.github.io/stage/beast/review/beast/design_choices/faq.ht…> A lightning talk from CppCon 2016 introducing Beast can be found here: <https://www.youtube.com/watch?v=uJZgRcvPFwI> Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Beast as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

24 107

Master branch now open for merging
by Marshall Clow 13 Jul '17

13 Jul '17

I will be uploading 1.65.0 beta1 this morning. Hint: It's the same as rc2 ;-) -- Marshall

2 1

[fiber] PR: Replace #include "Windows.h" by "windows.h"
by Frédéric Bron 13 Jul '17

13 Jul '17

Hi, A #include "Windows.h" causes troubles when cross-compiling on Linux in C++14 mode with MinGW-W64 with Posix threads. Can we change it to "windows.h"? Here is a PR: https://github.com/boostorg/fiber/pull/134 Thanks, Frédéric

2 2

[Boost.Range] Documentation
by degski 12 Jul '17

12 Jul '17

I had a need to try and understand Boost.Range. I don't know what to say, did this documentation pass a review? Introduction first "example": Example - Iterate over the values in a map using namespace boost; using namespace boost::adaptors; for_each( my_map | map_values, fn ); 3 lines, out of which 2 'using' lines, that make this "example" even less informative than it might have been without them, in wich case I would at least have known in which namespace(s) these things are living. Ah, wait, there's also an example section, so I'll copy the first example <http://www.boost.org/doc/libs/1_64_0/libs/range/test/string.cpp> in here: // Boost.Range library // // Copyright Thorsten Ottosen 2003-2004. Use, modification and // distribution is subject to the Boost Software License, Version // 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // // For more information, see http://www.boost.org/libs/range/ <http://www.boost.org/doc/libs/1_64_0/libs/range/> // //#define _MSL_USING_NAMESPACE 1 #include <boost/detail/workaround.hpp <http://www.boost.org/doc/libs/1_64_0/boost/detail/workaround.hpp>> #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # pragma warn -8091 // suppress warning in Boost.Test # pragma warn -8057 // unused argument argc/argv in Boost.Test #endif #include <boost/array.hpp <http://www.boost.org/doc/libs/1_64_0/boost/array.hpp>> #include <boost/range/as_array.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/as_array.hpp>> #include <boost/range/as_literal.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/as_literal.hpp>> #include <boost/range/functions.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/functions.hpp>> #include <boost/range/metafunctions.hpp <http://www.boost.org/doc/libs/1_64_0/boost/range/metafunctions.hpp>> #include <boost/static_assert.hpp <http://www.boost.org/doc/libs/1_64_0/boost/static_assert.hpp>> #include <boost/type_traits.hpp <http://www.boost.org/doc/libs/1_64_0/boost/type_traits.hpp>> #include <boost/test/test_tools.hpp <http://www.boost.org/doc/libs/1_64_0/boost/test/test_tools.hpp>> #include <boost/config.hpp <http://www.boost.org/doc/libs/1_64_0/boost/config.hpp>> #include <vector> #include <fstream> #include <algorithm> namespace { template< class CharT, std::size_t Length > class test_string { public: typedef CharT value_type; typedef value_type* pointer; typedef const value_type* const_pointer; typedef std::size_t size_type; typedef value_type array_t[Length]; typedef const value_type const_array_t[Length]; explicit test_string(const CharT literal_sz[]) { std::copy(literal_sz, literal_sz + Length, m_buffer.data()); m_buffer[Length] = value_type(); } const_pointer const_sz() const { return m_buffer.data(); } pointer mutable_sz() { return m_buffer.data(); } private: typedef boost::array<value_type, Length + 1> buffer_t; buffer_t m_buffer; }; } template< class T > inline BOOST_DEDUCED_TYPENAME boost::range_iterator<T>::type str_begin( T& r ) { return boost::begin( boost::as_literal(r) ); } template< class T > inline BOOST_DEDUCED_TYPENAME boost::range_iterator<T>::type str_end( T& r ) { return boost::end( boost::as_literal(r) ); } template< class T > inline BOOST_DEDUCED_TYPENAME boost::range_difference<T>::type str_size( const T& r ) { return boost::size( boost::as_literal(r) ); } template< class T > inline bool str_empty( T& r ) { return boost::empty( boost::as_literal(r) ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<Container>::type find( Container& c, T value ) { return std::find( str_begin(c), str_end(c), value ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<const Container>::type find( const Container& c, T value ) { return std::find( str_begin(c), str_end(c), value ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<Container>::type find_mutable( Container& c, T value ) { str_size( c ); return std::find( str_begin(c), str_end(c), value ); } template< typename Container, typename T > BOOST_DEDUCED_TYPENAME boost::range_iterator<const Container>::type find_const( const Container& c, T value ) { str_size( c ); return std::find( str_begin(c), str_end(c), value ); } std::vector<char> check_rvalue_return() { return std::vector<char>( 10, 'm' ); } using namespace boost; void check_char() { typedef boost::range_difference<std::string>::type diff_t; typedef char* char_iterator_t; typedef char char_array_t[10]; test_string<char, 8> a_string("a string"); test_string<char, 14> another_string("another string"); const char* char_s = a_string.const_sz(); char my_string[] = "another_string"; const char my_const_string[] = "another string"; const diff_t my_string_length = 14; char* char_s2 = a_string.mutable_sz(); BOOST_STATIC_ASSERT(( is_same< range_value<char_iterator_t>::type, detail::iterator_traits<char_iterator_t>::value_type>::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_iterator_t>::type, char_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_difference<char_iterator_t>::type, ::std::ptrdiff_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_size<char_iterator_t>::type, std::size_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_iterator_t>::type, char_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const char*>::type, const char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_value<char_array_t>::type, char>::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_array_t>::type, char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const char_array_t>::type, const char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_difference<char_array_t>::type, ::std::ptrdiff_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_size<char_array_t>::type, std::size_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<char_array_t>::type, char* >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const char_array_t>::type, const char* >::value )); BOOST_CHECK_EQUAL( str_begin( char_s ), char_s ); const diff_t sz = str_size(char_s); const char* str_end1 = str_begin( char_s ) + sz; BOOST_CHECK_EQUAL( str_end( char_s ), str_end1 ); BOOST_CHECK_EQUAL( str_empty( char_s ), (char_s == 0 || char_s[0] == char()) ); BOOST_CHECK_EQUAL( sz, static_cast<diff_t>(std::char_traits<char>::length(char_s)) ); BOOST_CHECK_EQUAL( str_begin( my_string ), my_string ); range_iterator<char_array_t>::type str_end2 = str_begin( my_string ) + str_size(my_string); range_iterator<char_array_t>::type str_end3 = str_end(my_string); BOOST_CHECK_EQUAL( str_end3, str_end2 ); BOOST_CHECK_EQUAL( str_empty( my_string ), (my_string == 0 || my_string[0] == char()) ); BOOST_CHECK_EQUAL( str_size( my_string ), my_string_length ); BOOST_CHECK_EQUAL( str_size( my_string ), static_cast<diff_t>(std::char_traits<char>::length(my_string)) ); char to_search = 'n'; BOOST_CHECK( find_mutable( char_s, to_search ) != str_end( char_s ) ); BOOST_CHECK( find_const( char_s, to_search ) != str_end(char_s) ); BOOST_CHECK( find_mutable( my_string, to_search ) != str_end(my_string) ); BOOST_CHECK( find_const( my_string, to_search ) != str_end(my_string) ); BOOST_CHECK( find_mutable( char_s2, to_search ) != str_end(char_s) ); BOOST_CHECK( find_const( char_s2, to_search ) != str_end(char_s2) ); BOOST_CHECK( find_const( as_array( my_string ), to_search ) != str_end(my_string) ); BOOST_CHECK( find_const( as_array( my_const_string ), to_search ) != str_end(my_string) ); // // Test that as_literal() always scan for null terminator // char an_array[] = "foo\0bar"; BOOST_CHECK_EQUAL( str_begin( an_array ), an_array ); BOOST_CHECK_EQUAL( str_end( an_array ), an_array + 3 ); BOOST_CHECK_EQUAL( str_size( an_array ), 3 ); const char a_const_array[] = "foobar\0doh"; BOOST_CHECK_EQUAL( str_begin( a_const_array ), a_const_array ); BOOST_CHECK_EQUAL( str_end( a_const_array ), a_const_array + 6 ); BOOST_CHECK_EQUAL( str_size( a_const_array ), 6 ); } void check_string() { check_char(); #ifndef BOOST_NO_STD_WSTRING typedef wchar_t* wchar_iterator_t; test_string<wchar_t, 13> a_wide_string(L"a wide string"); test_string<wchar_t, 19> another_wide_string(L"another wide string"); const wchar_t* char_ws = a_wide_string.const_sz(); wchar_t my_wstring[] = L"another wide string"; wchar_t* char_ws2 = a_wide_string.mutable_sz(); BOOST_STATIC_ASSERT(( is_same< range_value<wchar_iterator_t>::type, detail::iterator_traits<wchar_iterator_t>::value_type>::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<wchar_iterator_t>::type, wchar_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const wchar_t*>::type, const wchar_t* >::value )); BOOST_STATIC_ASSERT(( is_same< range_difference<wchar_iterator_t>::type, detail::iterator_traits<wchar_iterator_t>::difference_type >::value )); BOOST_STATIC_ASSERT(( is_same< range_size<wchar_iterator_t>::type, std::size_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<wchar_iterator_t>::type, wchar_iterator_t >::value )); BOOST_STATIC_ASSERT(( is_same< range_iterator<const wchar_t*>::type, const wchar_t* >::value )); typedef boost::range_difference<std::wstring>::type diff_t; const diff_t sz = str_size( char_ws ); BOOST_CHECK_EQUAL( str_begin( char_ws ), char_ws ); BOOST_CHECK_EQUAL( str_end(char_ws), (str_begin( char_ws ) + sz) ); BOOST_CHECK_EQUAL( str_empty( char_ws ), (char_ws == 0 || char_ws[0] == wchar_t()) ); BOOST_CHECK_EQUAL( sz, static_cast<diff_t>(std::char_traits<wchar_t>::length(char_ws)) ); wchar_t to_search = L'n'; BOOST_CHECK( find( char_ws, to_search ) != str_end(char_ws) ); BOOST_CHECK( find( char_ws2, to_search ) != str_end(char_ws2) ); #if BOOST_WORKAROUND(_MSC_VER, BOOST_TESTED_AT(1300)) BOOST_CHECK( find( my_wstring, to_search ) != str_end(my_wstring) ); #else boost::ignore_unused_variable_warning( my_wstring ); #endif #endif find( check_rvalue_return(), 'n' ); } #include <boost/test/unit_test.hpp <http://www.boost.org/doc/libs/1_64_0/boost/test/unit_test.hpp>> using boost::unit_test::test_suite; test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* test = BOOST_TEST_SUITE( "Range Test Suite" ); test->add( BOOST_TEST_CASE( &check_string ) ); return test; } Well, that obviously got me up and running, thanks. Is there any other documentation/examples to have a look at? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 1

[thread] Trying to cross build 1.64.0 boost.thread with mingw posix threads
by Frédéric Bron 12 Jul '17

12 Jul '17

Hi, I built a w64 cross-compiler to make windows binaries on linux. The cross-compiler has Posix threads, not win32 threads. I would like to build boost.thread with it but I have some difficulties: 1. I do not need to link with any library to build applications with C++11 threads but boost build asks for PTW32_INCLUDE and PTW32_LIB otherwise it sets <build>no so that the library is not built. This is easily changed with the following patch: diff -r -u boost_1_64_0-0/libs/thread/build/Jamfile.v2 boost_1_64_0-1/libs/thread/build/Jamfile.v2 --- boost_1_64_0-0/libs/thread/build/Jamfile.v2 2017-04-17 04:22:25.000000000 +0200 +++ boost_1_64_0-1/libs/thread/build/Jamfile.v2 2017-07-12 14:24:03.960979687 +0200 @@ -271,10 +271,6 @@ { result += $(paths) ; } - else - { - result = <build>no ; - } } result += <define>BOOST_THREAD_DONT_USE_CHRONO ; if ! [ configure.builds has_atomic_flag_lockfree 2. Once this patch is applied, the library is built but there are errors when compiling libs/thread/src/pthread/thread.cpp. The command that is run by b2 is given below. Here are the errors: libs/thread/src/pthread/thread.cpp:541:2: error: #error #error ^~~~~ In file included from ./boost/thread/thread_only.hpp:17:0, from libs/thread/src/pthread/thread.cpp:11: ./boost/thread/pthread/thread_data.hpp: In member function ‘void boost::thread_attributes::set_stack_size(std::size_t)’: ./boost/thread/pthread/thread_data.hpp:53:35: error: ‘getpagesize’ was not declared in this scope std::size_t page_size = getpagesize(); The first error is because apparently neither BOOST_HAS_SCHED_YIELD nor BOOST_HAS_PTHREAD_YIELD is defined. I understand that the 2nd error comes from the fact that getpagesize() is not in unistd.h provided by mingw-w64. There is a strange thing about the command line: it contains -mthreads although I never provided it. I tried to remove it or replace it with -pthread or -lptread but I still get the same error message. "i686-w64-mingw32-g++-7.1.0" -ftemplate-depth-128 -std=c++14 -O2 -DNDEBUG -O3 -finline-functions -Wno-inline -Wall -pedantic -march=i686 -mthreads -m32 -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_LOG_WITHOUT_EVENT_LOG -DB OOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DBOOST_USE_WINDOWS_H -DNDEBUG -DWIN32_LEAN_AND_MEAN -I"." -c -o "bin.v2/libs/thread/build/gcc-mingw-7.1.0/release/boost.locale.iconv-on/boost.locale.icu-off/boost.locale.std-o ff/link-static/target-os-windows/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp"

1 0

[root_ptr] Deterministic Javascript-like memory manager
by Phil Bouchard 12 Jul '17

12 Jul '17

Hello Boost / Qt, After some experience I have gained in Javascript over the last year, I decided to integrate root_ptr in a quest to replace their garbage collector. So I did and I already have an example. If we mimic the Javascript function scope in C++ then we'll have the following: https://github.com/philippeb8/root_ptr/blob/develop/example/javascript_exam… The application was compiled with: g++ -fpermissive -DBOOST_DISABLE_THREADS -std=c++11 -I../include -I/usr/local/include -L/usr/local/lib -lboost_thread -lboost_system javascript_example1.cpp And it outputs: Scope 0: BEGIN Scope 1: BEGIN A::A(const boost::node_proxy&) A::A(const boost::node_proxy&) A::~A() Scope 1: END A::~A() Scope 0: END Which is exactly what we want. Note that I didn't stress tested it yet and in Brave New World we would be able to integrate it to other languages relatively easily given Javascript is a worse-case scenario. What do you think? Regards, -Phil http://www.fornux.com http://www.finitetheory.com https://www.actatabula.com https://github.com/philippeb8/root_ptr/

3 10

[beast] Chunked Serialization, feedback requested! (Or: Bjorn, will you come out to play?)
by Vinnie Falco 12 Jul '17

12 Jul '17

During the review it was brought up that Beast could do a better job giving users control over the serialization and parsing of message payloads that have the chunked transfer coding applied. I collaborated with some helpful folks on the #boost slack channel and I have put together something solid for serializing chunks. I'm looking for feedback from anyone (especially Bjorn) before I merge this. The documentation is quite extensive and explains step by step how to achieve all of the goals stated in the review related to serialization of chunk encoded message payloads: <http://vinniefalco.github.io/stage/beast/bjorn/beast/using_http/chunked_enc…> I'm interested in hearing from anyone who cares to weigh in. Is the documentation sufficient? Are there any obvious defects? Do the interfaces meet the requirements for obtaining full control over the emitted chunked message payload? If anyone wants to play with or inspect the code, it is in the "bjorn" branch: <https://github.com/vinniefalco/Beast/commits/bjorn> In the meanwhile, I will start putting something together to provide better control during parsing of chunks. Thanks!

1 0

My Beast Review
by Phil Endecott 12 Jul '17

12 Jul '17

Dear All, This review is not very thorough - I've only looked at the docs and some small parts of the code, and read the discussion on the list. I've not tried to use the library. But I think I've seen enough to express an opinion. I've never used ASIO. I've studied it in the past, and concluded that it offers portability to platforms that I don't use but doesn't work well with other platforms that I do use. It also seems more complicated than I would have liked, perhaps in order to achieve some optimised level of performance that I don't need (or perhaps for no good reason). I have however quite often used HTTP (hasn't everyone?) and I think it's an embarrassment that std::c++ can't download something from the 'net with one or two lines of code in the way that almost every other language can. So, my first reaction is that it's a disappointment to see that a proposed HTTP library is tied to ASIO. On further investigation, however, I think this is no great loss to me as the functionality that this library provides is so limited in scope. Parsing HTTP headers, for example, is not much work. Even my own hacked-together-in-an-afternoon HTTP classes do more than this - to mention just one thing, parsing and formatting of dates in the correct format. Everyone who uses this library will have to implement this sort of thing themselves on top of it. (And many of them will implement it wrongly.) Vinnie says that he hopes that more functionality will be layered on top of this work. The danger is that the person who comes along wanting to implement the other 75% will not like Vinnie's starting point, and re-implement it all in their own style. (I know I would.) Unless, of course, Vinnie is going to offer this "other 75%" himself eventually. *That would be great*. If that is the plan, my review is "this is a fine start but please remove the ASIO dependency and come back when it's finished". But I think Vinnie has said that the library is to be reviewed "as is". In that case, my review is "just add this to ASIO and call it boost.asio.http and boost.asio.websocket, no need for a review" (assuming that the ASIO developer is happy with that). Regarding what I have seen of the implementation: - Security must be one of the most important properties of an HTTP library, and I'd really hope to find that such a library had been implemented by someone with significant experience in this area. I never cease to be amazed by the ingenuity of attackers. - I fear that there may be much premature optimisation in the parser code that I've looked at. For example: static bool is_digit(char c) { return static_cast<unsigned char>(c-'0') < 10; } Is that right? Say c='!' (ASCII 33). '0' is ASCII 48. So c-'0' is -15. But you cast that to an unsigned char, so -15 = 241, and 241 > 10, so the function returns false. So it is correct - but (1) it needs a comment to explain it, (2) it's the sort of thing that makes me worry from a security viewpoint, and (3) is it actually an improvement on the more obvious c >= '0' && c <= '9'? Well I've done a quick test and I get the same assembler for both - so why bother? (Except on close inspection actually I don't get exactly the same assembler. To get the same assembler I have to replace the constant 10 in your code with 10U, which changes the final comparison from signed to unsigned. I don't think that matters, but it again makes me wonder whether this security-critical code is ideal.) But hey, why even do c >= '0' && c <= '9' when we have std::isdigit()? But it would be much slower, right? Wrong, it's actually one instruction shorter; somehow it manages to avoid one of the zero-extension instructions. So this is not a premature optimisation, it's a premature pesimisation. (My test code is at the end of this message.) Now, is_digit is just about the simplest thing in the parser; Vinnie has also implemented his own code for parsing numbers, and then we come to parse_field. Please have a look at this (around line 666 of basic_parser.hpp). Note that it calls find_fast() near the top of that file, which uses some Intel SIMD instruction to, I think, skip forward over the header field name, and then over the field value to the CRLF. Not that there are any comments in find_fast to explain what it does, for those of us who don't know what _mm_loadu_si128 and _mm_cmpestri do. Has this code actually been benchmarked against a much simpler and more obviously-correct version, and found to have a worthwhile performance benefit? (I believe that some of the discussion has used this "optimised parser" as a justification for not making the code more generic, i.e. to work with any iterator pairs. I believe that to be flawed, since (a) I don't think this optimisation is useful, and (b) even if it were, the code could use it for any contiguous iterators, and fall back to "unoptimised" code in other cases. I think that having the "unoptimised" code present would be useful for documenting what the parser is trying to do, in any case.) Could it be that the reason why the scope of the library seems so limited is that Vinnie has spent his time fiddling with this optimisation, rather than adding useful features? My opinion: having looked at the implementation, reject. Test for is_digit: #include <cctype> bool is_digit_1(char c) { return static_cast<unsigned char>(c-'0') < 10U; } bool is_digit_2(char c) { return c >= '0' && c <= '9'; } bool is_digit_3(char c) { return std::isdigit(c); } Aarch64 assembler output from g++ 6.3.0 -O3, with the uninteresting bits removed: _Z10is_digit_1c: uxtb w0, w0 sub w0, w0, #48 uxtb w0, w0 cmp w0, 9 cset w0, ls ret _Z10is_digit_2c: uxtb w0, w0 sub w0, w0, #48 uxtb w0, w0 cmp w0, 9 cset w0, ls ret _Z10is_digit_3c: uxtb w0, w0 sub w0, w0, #48 cmp w0, 9 cset w0, ls ret Regards, Phil.

6 7

Outcome v2 is feature complete
by Niall Douglas 11 Jul '17

11 Jul '17

I am pleased to announce that Outcome v2, rewritten to fulfil the Boost peer review feedback from two months ago, has reached feature completeness. Outcome provides a 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. A detailed changelog over v1 can be found at https://github.com/ned14/outcome/blob/master/Readme.md. The main changes are the removal of lots of stuff which was in v1, and we now replicate `std::variant<...>` constructor API. v2 is an “absolute bare minimum” implementation with no frills. Outcome v2 is passing the modified v1 test suite handily, and v1 code should port to v2 easily enough. But as an all-new codebase it lacks: * Maturity * Polish * Use experience * Documentation (a class synopsis can be found at https://ned14.github.io/outcome/synopsis/) My hope is to return Outcome v2 for Boost peer review by October. If you are using an internal Expected-like object, or Outcome v1, I’d hugely appreciate it if you tried porting your code to using v2 and giving me feedback on how it went for you. Minimum compilers needed are GCC 6 or clang 4. Help with documentation and testing is also hugely appreciated. My thanks in advance! 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/

5 19

icl and C++17
by Duarte Nunes 11 Jul '17

11 Jul '17

Hi, Boost icl doesn't compile using GCC 7.1 with -std=gnu++17. There's a pull request solving the issue[1], but icl seems non-maintained. It would be great if someone could upstream that change so that projects depending on icl can get upgraded to C++17. Thanks, Duarte [1] https://github.com/boostorg/icl/pull/9

1 0

Re: [boost] [Boost-users] Boost 1.65.0 Beta 1 Release Candidate 2
by Marshall Clow 11 Jul '17

11 Jul '17

On Tue, Jul 11, 2017 at 4:06 AM, Raffi Enficiaud via Boost-users < boost-users(a)lists.boost.org> wrote: > Le 11.07.17 à 02:14, Marshall Clow via Boost-users a écrit : > > The second release candidates for the 1.65.0 beta release are now >> available at: >> >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.7z >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.tar.bz2 >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.tar.gz >> >> https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ >> boost_1_65_0_beta1_rc2.zip >> >> The SHA256 checksums are as follows: >> >> d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 >> boost_1_65_0_beta1_rc2.7z >> 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b >> boost_1_65_0_beta1_rc2.tar.bz2 >> 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 >> boost_1_65_0_beta1_rc2.tar.gz >> 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 >> boost_1_65_0_beta1_rc2.zip >> >> >> This RC contains a single fix to the stacktrace library. >> >> 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. >> >> Thanks! >> >> -- The release managers >> > > Hi, > > I have this error during the build on OSX. Built with: > ./b2 cxxflags="-std=c++11 -stdlib=libc++" linkflags="-stdlib=libc++" > --without-log --layout=versioned install > > > ...on 14200th target... > common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading-multi > common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- > multi/numa > darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- > multi/numa/pin_thread.o > libs/fiber/src/numa/pin_thread.cpp:23:10: warning: pin_thread() not > supported [-W#pragma-messages] > # pragma message "pin_thread() not supported" > ^ > 1 warning generated. > darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- > multi/numa/topology.o > libs/fiber/src/numa/topology.cpp:23:10: warning: topology() not supported > [-W#pragma-messages] > # pragma message "topology() not supported" > Given these two messages, I suspect that is deliberate. I see that too in my tests. -- Marshall

1 0

Fwd: [beast] (In)formal review
by Michael Caisse 11 Jul '17

11 Jul '17

Forwarding to the list: Received 1:19 AM my time... still July 10th in Hawaii ... and I'm still up reading Beast reviews so it seems good enough for me. Thanks for the review! -------- Forwarded Message -------- Subject: [boost][beast] (In)formal review From: Rüdiger Berlich ------------------------------------------- Dear Michael, dear Vinnie, having read the very lively discussion during the review, I am not sure I can add much to the technical side. Please feel free to either count this voice or leave it out, as you see fit, particularly as this mail didn’t come in time for the formal review. Hence I am sending this as PM. In my own applications, I limit myself to Boost as an external dependency. Having Websocket-functionality as part of Boost (the „pure“ HTML-side is of less significance to me) would be a god-send and would save me countless hours, allowing me to focus more on what I’m good at. Currently I just build directly on ASIO. I feel that Beast fills a very big niche and, having followed the development of the library for a while now, I am also confident that it is sufficiently advanced to be included into Boost. Thus, from a mere user’s perspective, I’d like to strongly vote in favor of ACCEPT. ============== - What is your evaluation of the design? I have worked with ASIO for a while and appreciate that Beast follows the same principles. - What is your evaluation of the implementation? I have browsed though some of the code and feel that it is well structured and certainly easier to read than some of the other Boost-code I have come across - What is your evaluation of the documentation? Beast does not intend to be a high-level library, and for the intended audience, the documentation is well-designed and complete. I would hope that, if and when Beast becomes part of Boost, there’ll be more tutorial-like information similar to what Boris Schaeling does in his books (e.g. here: https://theboostcpplibraries.com — could well become part of that). - What is your evaluation of the potential usefulness of the library? Immense. C++ is lacking a LOT of functionality on the library side, and this is one of the essential building blocks needed by people intending to create the higher-level libraries. I believe that we will see many new library proposals on top of Beast. - Did you try to use the library? With which compiler(s)? Did you have any problems? I have followed the development of Beast for a number of months and have „played“ with it in different contexts. I am in the process of integrating it into my own (client-server type application). In comparison to other libraries, it seems to be much more vivid and fast-paced. I have used it on MacOS and Linux (—> clang and g++). - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? No in-depth study, but in summary there is certainly more than a day of involvement. - Are you knowledgeable about the problem domain? Having done quite a bit of „do it yourself“ on top of ASIO for my own application, I appreciate what Beast can do for me (on the Websocket side) and am in dire need of this functionality. As a library-USER, I actually do not intend to be an expert for the implementation side and would be very thankful if it became available as part of Boost. I’d like to thank Vinnie for the huge amount of work that went into Beast and the Boost-community for the superb collection of libraries that have kept C++ alive. Kind Regards, Beet P.S.: I do not like the name „Beast“, but do not think it is important. Certainly this is up to the author to decide :-)

1 0

Encoding address-model in library names
by Peter Dimov 11 Jul '17

11 Jul '17

I have prepared the pull requests necessary to encode the address-model (32 or 64) in the library names, which allows placing the 32/64 libraries into the same stage/install directory, and building with address-model=32,64 in one go. These are https://github.com/boostorg/boost/pull/147 and https://github.com/boostorg/config/pull/159 This being a Serious Change, the prudent thing to do is to wait out 1.65, then proceed. On the other hand, experience shows that this kind of change is only tested when a release goes out anyway; delaying it for four more months would not help much. Therefore, I'm calling for opinions; would people want this to go into 1.65? Into 1.66? Not at all?

16 50

Boost 1.65.0 Beta 1 Release Candidate 2
by Marshall Clow 11 Jul '17

11 Jul '17

The second release candidates for the 1.65.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1_rc2.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1_rc2.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1_rc2.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1_rc2.zip This RC contains a single fix to the stacktrace library. 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. Thanks! -- The release managers

1 0

[mpl] [bug] Bug on python script
by Alessandro Marzialetti 10 Jul '17

10 Jul '17

Hello, I cannot open a ticket on the website due to an error OperationalError: could not extend file "base/19263/19289": No space left on device HINT: Check free disk space. Anyway, I found a bug in the library. The file is mpl/preprocessed/boost_mpl_preprocess.py a script that creates the headers required to have more than 50 types on a template. Basically the problem is on the string substitutions, with some values the output is wrong. I made a pull request that fixes the problem making a temporary substitution of the values https://github.com/boostorg/mpl/pull/29

2 1

[review][beast] Five-days Remaining
by Michael Caisse 10 Jul '17

10 Jul '17

Hi all - We are half-way through the review and have some great involvement and exchanges and a few reviews already. I hope if you haven't written a review yet that you still will. Please provide whatever effort you can afford toward the review process. Boost depends on community involvement. You might have noticed that I have solicited input from you regardless of your experience with the domain. I personally think it is a mistake to have input only from domain experts. True innovation often comes from "outsiders". If you have no experience with Asio or with HTTP, how approachable is this library? Were you able to understand the documents? Could you use the examples? Were you able to build something of your own? Domain experts -- you know the dark corners of the domain. The hard parts that have caused you hours of lost sleep and the need to hack around an existing library or to write your own. How does Beast address your concerns and the problems you have experienced in the past? Is it flexible enough to be put into your tool chest? So far we have reviews from: * Marcel Ebmer * Peter Dimov * Artyom Beilis * Zach Lain * Nik Bougalis * Klemens Morgenstern * Glen Fernandes If I missed a review from you, please let me know! Happy Coding! michael -- Michael Caisse Ciere Consulting ciere.com

6 13

[beast] Review
by Jens Weller 09 Jul '17

09 Jul '17

This is my review of the beast libary. First, I find the name quite fitting, but also we clearly need a "cage" library to make the internals of beast more useful for the endusers. I spend a few days on and off reviewing examples, and documentation. I used the library as an example for a fuzzing experiment on the weekend. What is your evaluation of the design? The design is very boost like, the library fits well into boost. One thing the library shares with asio is the buffer concept, which I never really liked. Buffer feels to me to abstract, to far away from the usual type vocabulary one is used to from standard C++. But once you're used to the concept, its ok. So no big deal. The dependence on Asio was already mentioned during the review and I am not sure about this. Surely a nice goal to have, but also not an easy one. But replacing asio with an abstraction that allows for pluggin in other socket implementations would be very powerful. Its nice that the library is header only, but over asio you get the dependency to boost::system for error_code. I'd love to be able to exchange boost::error_code dependency to the std::error_code one. As the beauty of header only really shines when you don't need to link to other non header only libraries... What is your evaluation of the implementation? Fuzzing. I spend this weekend some time to fuzz beast with libFuzzer. The basic_parser and the websocket::stream were fuzzed. A bug (buffer overflow) in basic_parser was found, and is already fixed. What is your evaluation of the documentation? Boost typical. Its good, helps with getting the library to know. What is your evaluation of the potential usefulness of the library? This library could be the foundation of many things to come. The internet is the basic building block for so much today, that beast is a nice improvement upon asio in providing the vocabulary to use boost in the internet age. As I already mentioned, I think that other libraries are needed in order to make this library really useful for most end users. But the scope the author aims at, beast fits very well. Did you try to use the library? With what compiler? Did you have any problems? Fuzzing was based on clang 5.0, but I also used the library with GCC 5.4 to generate example data for the fuzzing. I plan to use the library to write a small http server and clients for my own usage. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? My time for this review is limited, but as the author mentioned on this list, that the library hasn't been fuzzed, I aimed for doing this instead of implementing an http client/server. I still had to write code in order to reach the parts in beast to be fuzzed, this gave a more detailed tour of beast, then one would need for simple example exploring. Are you knowledgeable about the problem domain? A little, I am mostly a high level user of various HTTP libraries, but not at the low level beast covers. I found it interesting to get a glance at the details. And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. I think that this library should be ACCEPTED into boost. It is an important improvement on asio, in order to offer a more detailed networking stack in boost. The library has the exact right scope to do this, widening the scope into providing client/server implementations would not be good. I see this in another library. thanks, Jens Weller

3 4

Boost 1.65.0 Beta 1 Release Candidate 1
by Marshall Clow 09 Jul '17

09 Jul '17

The release candidates for the 1.61.0 release are now available at: https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.7z https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.bz2 https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.gz https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.zip The SHA256 checksums are as follows: cd7429340bb4aae38e0ad2e9f59c39e66335302c41577956123e55fc1e2a28ee boost_1_65_0_beta1_rc1.7z fda076f7b3c994524d9cd41926c72f4a9b7c017bef310a055956fdd0bed7c358 boost_1_65_0_beta1_rc1.tar.bz2 0d1473041f7a9fa9ce1e256c870cc52af6f98abf723cf4f1ac61c2b45f45d38a boost_1_65_0_beta1_rc1.tar.gz f45bbb75b84cdc0c66f8a571d77c518cfbac076d7a6fc7937c4812f0f242a792 boost_1_65_0_beta1_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. Thanks! -- The release managers

4 5

[Safe Numerics] Review
by John Maddock 09 Jul '17

09 Jul '17

OK, here's my review of Robert's library. By way of something different, I've tried to not read the docs (though I ended up scanning them in the end) and just tried to use the library. Here's what I've found: 1) Using: safe<int>(-1) & 1 I get a hard assert failure at safe_base_operations.hpp:1373. I'm assuming that this is a mistake, and the usual error handlers should be called? Bitwise or has the same issue. More tests required ;) 2) I'm not sure if this is an msvc issue but in: constexpr safe_base operator~() The static assert is triggered for *unsigned types* and not for signed. Even if this is a compiler issue, it indicates a missing test case or two. 3) If I assign a float to an integer, then I get the error: "conversion of integer to float loses precision" which isn't quite what you meant to say. More particularly, for float conversions I would expect: * Conversion from a float holding an integer value that's within the range of the target type to always succeed. * Conversion from a float holding a non-integral value to conditionally succeed (with trunction) depending on the policy in effect. * Conversion *to* a float may also fail if the integer is outside the range of the float (no checking may be required if the number of bits in the integer is less than the number of bits in the float). 4) Is constexpr arithmetic supposed to be supported? I tried: constexpr boost::numeric::safe<int> j = 0; constexpr boost::numeric::safe<int> k = 3; constexpr boost::numeric::safe<int> l = j + k; Which generates an internal compiler error for msvc, and for gcc-5.3 I get: ../../../include/safe_base_operations.hpp:332:35: error: call to non-constexpr function ‘void boost::numeric::dispatch(const boost::numeric::checked_result<R>&) [with EP = boost::numeric::throw_exception; R = int]’ dispatch<exception_policy>(r); Similarly if I try to add a literal to a safe<int>. Again as the tests all pass, so I'm assuming they're missing constexpr tests? 5) What is the purpose of class safe_literal? constepxr initialization seems to work just fine without it? 6) In the docs, the example of using error handler dispatch is nonesense (top of page 41)? 7) Related to the above, I see the need to be able to define your own primitives which behave just like yours. The example I have is for bit-scan-left/right which has as precondition that the argument is non-zero, but there are other bit-fiddling operations (bit count etc) which some folks may require. A "cookbook" example would be good. 8) In the tests, you have an undocumented function "log" in the library. Not sure if this is intended to be part of the API or not, but IMO it's misnamed. ilog2 seems to a semi-standard name for this. 9) By way of testing the libraries performance I hooked it into the Millar-Rabin primality test in the multiprecision lib (test attached, it counts how many probable primes there are below 30000000), here are the times for msvc: Testing type unsigned: time = 17.6503 seconds count = 1857858 Testing type safe<unsigned>: time = 83.5055 seconds count = 1857858 Testing type 32-bit cpp_int: time = 36.9026 seconds count = 1857858 and for GCC-MINGW-5.3.0: Testing type unsigned: time = 17.1037 seconds count = 1857858 Testing type unsigned: time = 18.4377 seconds count = 1857858 Testing type unsigned: time = 21.0592 seconds count = 1857858 I'm surprised by the difference in times between msvc and gcc, also deeply impressed that there is effectively no performance penalty with GCC (I was expecting there should be some!) 10) I don't find the scope of the library over-broad, in fact I probably find it about right wrt the policies etc. 11) There were a few traits and such that it would be nice to have, the problem as ever, is what to call them and where to put them: * A trait for extracting the underlying type of a safe<> - use case for example where you enable_if a function on is_safe so don't have the template argument list to safe<>. * Do we need a function for extracting the underlying type of a safe<>? Or is casting to the underlying type optimal? Actually, maybe having a function would negate the need for the above trait, as we could just write 'auto x = mysafe.value();' ? * Do we need traits equivalent to is_signed/is_unsigned/make_signed/make_unsigned? My gut feeling is yes we do, the issue is what to call them, and where to put them - we're not allowed to specialize the type_traits versions (either boost or std), but we would need a central "one true trait" version that can be specialized by other libraries as well (Multiprecision for example). We've backed ourselves into a corner over this I fear! 12) When calling boost::integer::gcd/lcm the sub-optimal(?) non-binary versions are called for safe<> - you might want to look into seeing what traits need to be defined to ensure that the same version as the underlying type is called. Those are all the issues I can see for now... in conclusion, as for whether the library should be accepted, yes I believe it should be, modulo the issues above. Regards, John. --- This email has been checked for viruses by AVG. http://www.avg.com

4 14

Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
by Vinnie Falco 09 Jul '17

09 Jul '17

On Mon, Jul 3, 2017 at 9:54 AM, Emil Dotchevski via Boost <boost(a)lists.boost.org> wrote: > ... > The question is must Beast be coupled to Asio, not can it be used without > something like Asio. And I don't mean just in the case of someone using > serializer/basic_parser and nothing else. > > In my opinion, arguing that coupling is necessary should begin with > defining an interface which Beast can use, which can be trivially > implemented in terms of Asio. In designing this interface the only concern > should be avoiding the coupling; specifically, performance considerations > should be completely ignored. Only then we can have a reasonable discussion > is it worth it. Regardless, in my experience this kind of exercise always > improves the design of a library. The question is, can Beast be written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams, instead of being tied to Boost.Asio? First lets imagine what such generic concepts might look like, independent of Beast. We will start with the synchronous case which is the easiest. In the code which follows: * `Stream` is a type representing a buffer oriented I/O stream * `Buffers` is type representing an ordered sequence of zero or more non-owning references to contiguous octet buffers * `Error` is type representing an error code The following synchronous stream operations are defined: /** Read data from a stream synchronously `stream` The stream to read from `buffers` The buffers to read into `error` Set to the error if any occurred. returns: The number of bytes transferred, or 0 on error. */ std::size read( Stream& stream, Buffers const& buffers, Error& error); /** Write data to a stream synchronously `stream The stream to write to `buffers The buffers to write from `error` Set to the error if any occurred. returns: The number of bytes transferred, or 0 on error. */ std::size_t write( Stream& stream, Buffers const& buffers, Error& error); This looks pretty generic and at this point users familiar with Boost.Asio might raise their hands to tell me that the interfaces look identical. This is just a coincidence because, lets face it - synchronous interfaces don't come in that many varieties. I don't think synchronous interfaces are particularly interesting and Beast could certainly be made to use something like this but even with simple interfaces some issues come up: 1. What is the concrete type of Error? Or is Error a template parameter that meets certain requirements? 2. HTTP stream read algorithms need to know when the stream, is closed, what error code represents End-of-File? 3. What are the requirements of Buffers? Beast could be written against generic concepts, but in order to do so the questions above need to be answered (points 1 through 3). Otherwise there is no specification and thus, no way to write an algorithm. We will come back to these questions, but now on to the next topic. We want Beast to also provide HTTP operations on asynchronous streams, so we need to have a generic concept against which to work. There are many models of asynchronous computation. For example there are futures, coroutines, callbacks, and queues (I can't really think of any others at the moment). Lets imagine what callback-based generic asynchronous stream read and write operations might look like: In the code which follows: * `Stream` is a type representing a buffer oriented I/O stream * `Buffers` is type representing an ordered sequence of zero or more non-owning references to contiguous octet buffers * `Error` is type representing an error code * `Callback` is a type which is Callable with the signature `void(Error, std::size_t)` The following asynchronous stream operations are defined: /** Begin an operation to read data from a stream asynchronously `stream` The stream to read from `buffers` The buffers to read into `callback` A callback to invoke when the operation completes. The callback will receive the error if any, and the number of bytes transferred. returns: The number of bytes transferred, or 0 on error. */ void async_read( Stream& stream, Buffers const& buffers, Callback const& callback); /** Begin an operation to write data to a stream synchronously `stream` The stream to write to `buffers` The buffers to write from `callback` A callback to invoke when the operation completes. The callback will receive the error if any, and the number of bytes transferred. returns: The number of bytes transferred, or 0 on error. */ void async_write( Stream& stream, Buffers const& buffers, Callback const& callback); Now anyone who knows Asio is going to stop me and say, hey! This looks a lot like Asio! But that's a side issue because this generic interface I have provided has some defects. Or rather, you can say that it is under-specified. We have the same questions about the requirements for the types Error and Buffers, and the value representing End-of-File. But now there are even bigger questions with significant ramifications: 1. Upon which thread is the callback invoked? 2. Who invokes the callback and how is it invoked? 3. How is access to the `stream` synchronized? 4. What about futures and coroutines? The simple generic free function signatures alone which I provided above are not sufficient to describe a complete model for asynchronous operations on streams. We also need provisions to answer the questions above. Does the implementation provide the threads, or are they provided by the user? Does synchronization use mutexes? Lock-free programming? Queues? Back to this in a moment... Some folks who either dislike callbacks or just happen to love futures may raise an objection that the callback-based generic model I have described does not capture their use case. Actually, Christopher Kohlhoff (author of Boost.Asio) demonstrates how the callback-based model is a proper superset of all other asynchronous computation models. And he shows that callback-based models provide the greatest opportunity for performance and efficiency by doing away with unnecessary synchronization points. This is explained in his paper N3896 "Library Foundations for Asynchronous Operations" and shows how initiating functions like `async_read` and `async_write` above may be trivially modified to support not just callbacks but also futures, coroutines, and user-defined types. Beast fully supports this system and even comes with tutorials and helper classes which let you implement the model yourself in your own initiating functions. "Library Foundations for Asynchronous Operations" (N3896) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3896.pdf> "Writing Composed Operations" (Beast) <http://vinniefalco.github.io/stage/beast/review/beast/using_networking/writ…> Thankfully this solves one piece of our puzzle. N3896 allows us to say with certainty that our hypothetical generic network model should use callbacks as the foundational notification mechanism for the completion of asynchronous operations. Perhaps we can look towards the author of N3896 for more solutions? Drumroll... Working Draft, C++ extensions for Networking (N4588) a.k.a. "Networking-TS" <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4588.pdf> What is this you ask? Well... this is a working draft which describes a proposed set of C++ extensions for Networking. It has TCP/IP sockets and UDP streams, serial ports I think (?) but lets not worry about that. Most importantly, the Networking-TS defines a generic model for synchronous and asynchronous stream-oriented I/O operations! This means that: Synchronous and asynchronous algorithms written against Networking-TS concepts will work with any stream types that meet the requirements ** Yes, Networking-TS comes with generic stream concepts. Lets restate the original question: "Can Beast be written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams?" The answer is: Yes. Beast is already written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams. These are provided by Boost.Asio. Specifically, these concepts: SyncReadStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.stream.reqmts.sync…> SyncWriteStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.stream.reqmts.sync…> AsyncReadStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.async.read> AsyncWriteStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.async.write> Its not the responsibility or goal of Beast to invent a new generic model of synchronous or asynchronous networking. That's already been taken care of. Beast follows it. It is the job of authors to make sure their network implementations meet the requirements of the various Networking-TS stream concepts. Once they do that, then any algorithms written against the concepts can now work with these implementations. Again folks might raise their hand and say "but Beast depends on Boost.Asio!" and they would be right. The reality is that Networking-TS has not entered the standard and is not uniformly available across compiler vendors. Boost.Asio is the closest thing to the standardized version of Networking-TS, so Beast is written against that. Its not perfect, but it is the best we can do and the runner-up is not even in the race (are there any other generic stream designs?). I believe that the burden of proof rests with those who claim that Beast should be written against a different generic stream design. Please show me one such design that is mature, well-specified, and in-use, other than Boost.Asio. tl;dr; Boost.Asio's models of synchronous and asynchronous buffer-oriented streams are already generic, and Beast is written against Boost.Asio. Thanks

2 1

Re: [boost] Boost 1.65.0 Beta 1 Release Candidate 1
by berne＠notadragon.com 09 Jul '17

09 Jul '17

Hi, I've been playing aournd with boost coroutines2 and maybe I'm just confused about where this project is, but with 1.65 coroutines2 doesn't seem to be buildable out of the box any longer: I've tried looking through mailing list archives for anything about the status of coroutine2 to no avail, and coroutine still spits out warnings to use coroutine2 when used. I'm not sure where in the build system things hook in to fix this. Here's the output on my system: berne@Bugg:~/tmp$ tar xzf boost_1_65_0_beta1_rc1.tar.gz berne@Bugg:~/tmp$ cd boost_1_65_0/ berne@Bugg:~/tmp/boost_1_65_0$ ./bootstrap.sh --with-toolset=clang Building Boost.Build engine with toolset clang... tools/build/src/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in project-config.jam... Bootstrapping is done. To build, run: ./b2 To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/build/doc/html/index.html berne@Bugg:~/tmp/boost_1_65_0$ ./b2 --with-coroutine2 error: wrong library name 'coroutine2' in the --with-<library> option. Thanks. - Josh

2 2

[beast] Review
by Gyorgy Szekely 09 Jul '17

09 Jul '17

Hi, Some background: this is my first Boost library review. I followed the discussion on Beast and I'm probably not as experienced as others on this topic. I started learning Beast along with Asio and it was a really good experience. After understanding ASIO concepts, I could get an async multi-threaded http server running in a few hours. I leave it up to the review manager whether to take this a formal review or just informal feedback (impressions of newbie :)) *** What is your evaluation of the design? The library in my opinion is very well designed. I doesn't try to offer too much. I understand the author's position: HTTP is vast and Beast is a low-level library. Still, while using it I felt with a few additional bits it would be more complete. What I was missing is parsers/serializers for uri and cookies. I think Beast should provide these (even in a separate namespace), as they are not higher level functionality than parsing/serializing http headers. (I implemented them in my application, and I'm sure my code is neither correct regarding corner cases, nor standards compliant. I'm also sure that I'm not alone with this, so there's a place for this in either Beast, or as the author suggests a higher level lib.) Though the library is heavily templated, as a user I'm not forced to write templated code, implementing the most common use-cases is simple and straightforward. That's a big plus. I really like the symmetric client/server design. My application is http/websocket server, being able to use the the same classes and functions in unit tests made reasoning about the code and tests much easier. Finally there's was a lot of debate whether being ASIO and stream concept based is a good idea or not. For me (as a newcomer) seamless integration with ASIO helped getting started really fast, though I didn't do awfully complex stuff. *** What is your evaluation of the implementation? I did not review all the implementation. While using the library, I looked into some of the files, and my impression was that the code is high quality. The test coverage is also high, and issue fixes are accompanied with rigorous tests. The library is mostly composed of templates, which makes a bit harder to understand its internals, but I didn't mind it at all given the benefits (composablity, customization points). *** What is your evaluation of the documentation? The documentation is well structured and plenty. Sections from the Intro up to the Reference are a good read by themselves. Design decisions and library scope are clearly stated. There're lots of examples in form of code snipets highlighting a particular use-case, as well as fully functional programs demonstrating these in action. I liked that the documentation is similar to ASIO's and I could use them together. *** What is your evaluation of the potential usefulness of the library? It's super useful. Even with its (current) dependency on ASIO and some other Boost libs Beast is small while providing both client and server side foundations for Websocket and HTTP. NodeJS and Java makes it so simple to create REST services, this should be hard in C++ either with standards based (NetTS) solutions. Beast is a step in the right direction. *** Did you try to use the library? With which compiler(s)? Did you have any problems? I'm actively using the library in the Http/Websocket <-> ZeroMQ gateway since Oct 2016 on Ubuntu 16.04 with GCC5, C++14. We've run extensive performance and stability tests on the HTTP interface and we're quite satisfied with the results. I migrated our codebase to newer Beast versions multiple times, and during this I reported a few minor issues or requested new features. The library author was really responsive and fixed/implemented them quickly. *** How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours this time, but I've read the documentation and the public API reference multiple times in the last months. I didn't go through the implementation, but peeked into it here and there to understand some of the details. *** Are you knowledgeable about the problem domain? Not really. I've implemented some NodeJS and Java Spring REST services, but that's all. My conclusion: Beast should be ACCEPTED. Regards, Gyorgy Szekely

1 0

[sort] pdqsort mini-review
by Steven Ross 08 Jul '17

08 Jul '17

The (mini) review for pdqsort will start tomorrow 6/21, and run through 6/30. I will manage the review; Orson Peters is the author. The proposed boost source is here: https://gist.github.com/orlp/24f27aada1ed724d1809b372c33eb92e Documentation is here: https://github.com/orlp/pdqsort#pdqsort And a draft paper is here: https://drive.google.com/open?id=0B1-vl-dPgKm_T0Fxeno1a0lGT0E If you're interested, please answer these questions: 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort?

7 10

[review] Mp11 review starts in one week
by Bjorn Reese 08 Jul '17

08 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

[beast] Missing documentation link
by Bjorn Reese 08 Jul '17

08 Jul '17

The link to example/common/file_body.hpp in the Examples section has gone missing. Please fix this ASAP. All links in the Examples section point the the master branch instead of the review branch.

2 2

[bootstrap] [b2] [install] Intel 17.0 & b2 cmd file for intel64 & vs2017
by Robert 07 Jul '17

07 Jul '17

Hello Everyone, I have had zero responses on the boost-build list since posting June 23, 2017. Hopefully there will be some here. This is most definitely not urgent. There is a chance that a solution in this thread may be important enough to add to a 1.65 jam file. There are many details in order to fully describe the situation. Executive Summary: In order to correctly build Boost 1.64 with the Intel 17.0, Update 4, C++ Windows compiler, in conjunction with Visual Studio (VS) 2017, Update 2, a symbolic link is necessary. The link shortens the VS installation root path for b2.exe to execute correctly. There is a question regarding the correct implementation to modify one or more jam files. The b2.exe automatic detection of the new and different Visual Studio 2017 paths is not working correctly. Details: I have succeeded constructing the b2 complete install for Intel 17.0, Update 4 on Windows 8.1 Pro, 64-bit, in conjunction with Visual Studio 2017, Update 2 (e.g. 15.2 (26430.12), in the About Microsoft Visual Studio dialog). The zlib source and Python 2.7 libraries are also incorporated into the x64 Boost by Intel build. In order to achieve a successful outcome, I create a symbolic link with the mklink command to considerably shorten the value for the VS2017INSTALLDIR environment variable. The value VS2017INSTALLDIR is first set to is: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise The content above triggers two, "input is too long," messages when executing the .\b2 install --prefix=C:\Boost command. The execution never creates the respective b2 cmd file (file name listed below). The Intel supplied batch file is looking for the VS2017INSTALLDIR environment variable, when the vs2017 option is passed to compilervars.bat: compilervars intel64 vs2017 The location of the compilervars.bat is in something similar to: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.4.210\windows\bin Please review https://software.intel.com/en-us/articles/building-boost-with-intel-c-compi… for the recent details from Intel, to build Boost with the Intel compiler on a Windows operating system. The symbolic link is C:\v7 pointing to: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise When the VS2017INSTALLDIR environment variable is C:\v7, then the execution of b2 install at <boost root>\tools\build creates the 32-bit and 64-bit b2_intel-win_17.0_iclvars... command files in C:\Users\<username>\AppData\Local\Temp. I would like to understand whether the b2 constructed output for the file named: b2_intel-win_17.0_iclvars_intel64 vs2017.cmd should have its internal DevEnvDir variable value as this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ or this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ If the answer is the latter, then what is the correct modification(s) to the intel-win.jam, user-config.jam, and/or msvc.jam to enable the automatic detection to find the correct location for VS2017's devenv.exe? In order to use the 14.1 Visual Studio version string value, the 1.64 intel-win.jam file has been modified accordingly near the last line: .iclvars-17.0-supported-vcs = "14.1 14.0 12.0 11.0 10.0" ; .iclvars-version-alias-vc14.1 = vs2017 ; I have manually replaced the following strings of the b2_intel-win_17.0_iclvars_intel64 vs2017.cmd file to use the new Visual Studio 2017 paths. For example, the following older VS 2015 paths are equivalent to the following new VS 2017 paths (using the C:\v7 symbolic link above). Note that some paths are very long in VS2015. The VS2017 equivalent can be longer. The replacement string is preceded by the "==>" character combination. C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VC\ ==> C:\v7\Common7\IDE\VC\ C:\Program Files (x86)\MSBuild\14.0\bin\amd64 ==> C:\v7\MSBuild\15.0\Bin\amd64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 ==> C:\v7\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages ==> C:\v7\Common7\IDE\VC\vcpackages C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE ==> C:\v7\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools ==> C:\v7\Common7\Tools C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\x64 ==> C:\v7\Team Tools\Performance Tools\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools ==> C:\v7\Team Tools\Performance Tools\ C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow ==> C:\v7\Common7\IDE\CommonExtensions\Microsoft\TestWindow C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ ==> C:\v7\Common7\IDE\PrivateAssemblies\ The affected cmd variables are: DevEnvDir INCLUDE LIB LIBPATH Path VCIDEInstallDir __VSCMD_PREINIT_INCLUDE __VSCMD_PREINIT_LIBPATH __VSCMD_PREINIT_PATH Thank you for your time and attention. It is greatly appreciated. Sincerely, Robert

1 0

[beast] Review
by Marcel Ebmer 07 Jul '17

07 Jul '17

Here's my Review: DESIGN ====== The design of concepts, data structures and algorithms is mostly done well, with only minor concerns: - The smell of two-phase initialization. Required message properties like method and target have to be set from outside. This makes me as a library user afraid of forgetting something vital. The same holds for prepare_payload(). If I forget to call prepare_payload() or forget to set one of the required message properties or fields, my program may - in the worst case - appear to work correctly. - Inconsequent application of automagic. WebSocket control frames are automagically responded to. Iff there's an active read(). Basically, having an active read() at almost all times is a requirement of any correct program using Beast. Even though I enjoy the help from the library, and the requirement is usually met, I found this specific behaviour to be inconsequent. Also, the very first WebSocket example in the docs makes it clear that while a close from the peer is handled automagically under the above condition, a close from my side is quite tedious to write. There should be a utility in the library to do the draining for me. - The naming of BodyReader and BodyWriter initially got me confused. In my mind, I 'read' a body FROM a stream/buffer, I 'write' it INTO a stream or buffer. The library uses the terms in the reverse sense. This is not incorrect of course, but my initial confusion may be a sign of suboptimal naming. IMPLEMENTATION ============== Didn't look in-depth. DOCUMENTATION ============= The documentation is very well structured. It is complete in many, but not all places. - A minimalistic HTTP server example would have helped me get started. Just something very, very basic. Reply to each request with "your request was". - In some places, non-self-explanatory function names suddenly pop up without being first introduced. For example, in the section "Using WebSocket"."Send and Receive Messages", text() and got_text() could use some explanation. In the same section, the reference to set_option() seems out-of-place and makes me wonder what I missed. - Since the documentation features comparison with other libraries, it may be worth comparing pion (https://github.com/splunk/pion) as well. - Many reference pages could use some prosaic explanation. For example, my uncertainty concerning message.prepare_payload() might have been alleviated, were it more clear what the function is intended for and what the effect of omitting it would be. SCOPE ===== Since the FAQ is quite defensive in regard to the library's scope, I feel this is worth some discussion. I found the scope to be just right for now, but with future potential. As it is, the library takes away all the tedious protocol stuff, while leaving all important design decisions to the user. It feels like an extension to ASIO. However, there's no apparent reason why (e.g.) request targets shouldn't be URL-decoded, and why form data should not be parsed into a map of some kind. The way I see it, none of this added funtionality would interfere with the library's design. It would, however, make the library user's life a whole lot easier, and probably attract more users as well. USEFULNESS ========== See SCOPE. Very valuable, could be even better. HOW MUCH EFFORT & TRIED TO USE ============================== I invested about a day into the review, read the documentation and ported a small REST-like service from pion to Beast. I may be biased towards Beast due to temporal proximity, but I feel the latter made the code easier to reason about and, at the very least, did not hurt performance. I used gcc 7.1 and clang 4.0. On the review branch, none of the two had any issues. I deliberately did NOT follow the discussion on the mailing list, in order to remain as unbiased as practicable. HOW KNOWLEDGABLE AM I? ====================== I have worked on several HTTP servers and experimented with writing an HTTP server library a few years back. I have no practical experience with WebSockets. IN ONE SENTENCE =============== Beast should be ACCEPTED into Boost. Marcel

2 3

[build] No output until an action completes?
by Tom Westerhout 07 Jul '17

07 Jul '17

Greetings! I've run into a problem that a Boost.Build action produces no output until the command returns. For example, in my Jamfile I have rule do-measure ( test-name : sources * : requirements * ) { ... some preparation work ... } actions do-measure { $(COMMAND) $(ARGS) } notfile ha : @do-measure : ... : ... ; COMMAND is a Python script that runs for a long time and produces some debug information. But b2 does not print this output until COMMAND returns. This is really unfortunate because Travis requires a command to produce output at least once per 10 mins or something. Otherwise it thinks the command has stalled and terminates it. Is there some configuration parameter or a trick to make b2 print the debug info COMMAND produces? or maybe some dummy output so that Travis allows it to run longer than 10 mins? Any help is highly appreciated! Tom

2 2

Serialization support for small_vector
by Brian Wood 07 Jul '17

07 Jul '17

Shalom I've added support for small_vector to the C++ Middleware Writer. While testing the support, I got a warning about dereferencing a type-punned pointer breaking strict-aliasing rules. That was on line 340 of small_vector.hpp. I was using g++ 7.1 on FreeBSD/ TrueOS. I used the following "Middle" code for testing: message-lengths variable example_messages -out (message_id_8, ::boost::container::small_vector<int32_t,30>) -in (::boost::container::small_vector<int32_t,30>) } >From what I could tell the serialization/deserialization worked fine. If small_vector were broken out into a separate library that would be helpful from my perspective. It would make it easier for me to add small_vector to my example code. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

[CallableTraits] Review results
by Louis Dionne 07 Jul '17

07 Jul '17

Dear Boost, I am pleased to announce that the CallableTraits library is CONDITIONALLY ACCEPTED into Boost. I counted the following formal reviews: - Bruno Dutra: Yes - Emil Dotchevski: Yes - John P. Fletcher: Yes - Klemens Morgenstern: Yes - Peter Dimov: Yes - Zach Laine: Yes The following people also participated to the review by providing informal feedback: - Edward Diener - Gavin Lambert - Niall Douglas - Paul Fultz II - Tim Song I also based my decision on previous experience I've had using the library, and some issues we faced in the Standard Committee where we could have used CallableTraits. I'd like to thank everyone who participated to the review for their feedback, and also Barrett Adair for his submission. The following lists the conditions for acceptance, and also summarizes the general feedback received during the review. GitHub issues are leveraged to make the tracking of these comments easier. Below, whenever I refer to #XYZ, the corresponding ticket can be found at https://github.com/badair/callable_traits/issues/XYZ To see all the issues that were discussed during the review, you can search for tickets labeled with `review` on GitHub (please allow some time for Barrett to update the new issues I just filed): https://github.com/badair/callable_traits/issues?page=1&q=+label%3Areview Conditions for acceptance ------------------------- The following are points that must be addressed for the library to be accepted. Once all of the associated GitHub issues are closed, I ask that the author post to this list with links to the closed issues. Unless major problems (having to do with the closed issues) are raised at that time, the library will be automatically accepted into Boost, no additional review required. - The library needs to clearly document the advantages of CallableTraits over FunctionTypes. Concrete examples must be given (at least one, preferably two). See #117. - The level of C++ conformance required for the whole library needs to be clearly stated in the documentation. Individual components should only document divergences from that base level of conformance. The current state of things is quite confusing for users. See #118. - The "algorithmic" parts of the library must be removed, since they are out of scope. This has already been partly done in issue #114, but the following algorithms must be discussed too (let's follow up in #114): + args_at + clear_args + pop_front_args + push_front_args + expand_args_right + expand_args_left - The lazy metafunctions and predicate traits should be SFINAE-friendly, just like the aliases are. I think this inconsistency is a big deal, enough to be a condition for acceptance. See #134. Summary of the feedback received -------------------------------- The following is a compilation of other points that were made during the review, but which are not requirements for acceptance. I trust, but do not require, that all of those points will be considered by the author: - There is a loss of information with the `args` metafunction. For example, `void(T)` and `void(T, ...)` both give the same result. See #132. - Consider adding a way of obtaining the parameter list of a function without the type of `*this`. See #133. - The documentation uses the terms of art "implementation defined" and "undefined behavior" incorrectly. See #103 and #131. - The non-reference documentation should present at least one real-world use case. See #116. - The library should handle top-level cv-qualifiers. See #106. - Consider supporting different calling conventions (e.g. `__cdecl`). See #102. - Consider adding a pre-C++17 implementation of `is_invocable` and friends. See #119. - The documentation should clearly state that the library can be used without the rest of Boost. See #99. - Consider combining `expand_args` and `args` into a single metafunction with a default "output" parameter of `std::tuple`. See #126. - Consider adding `make_fn` and `make_mem_fn` metafunctions to construct a signature from a return type and a tuple of the arguments. See #113. - Consider renaming some traits, like `is_reference_member`. See #108. - Reword some parts of the documentation that look odd due to the use of passive tense. See #105. - Consider adding a version of `apply_member_pointer` which carries cv-qualifiers. See #138. - Consider adding `remove_member_cv_ref` and `copy_member_cv_ref`. See #139. - Why does `qualified_parent_class_of` always returns a const& for PMDs? See #112. - Why does `qualified_parent_class_of` return a ref-qualified type even for unqualified PMFs? See #112. A few of my own comments: - Consider using alphabetical order in the table of contents of the reference. See #135. - Consider renaming `apply_member_pointer` to something like `make_member`. See #136. - Consider dropping the `parent_` in `parent_class_of`, or adding a note to justify the name. See #137. Again, thanks to everyone who participated in the review, and congratulations to Barrett for his work! Regards, Louis Dionne

2 3

[beast] Chunking example
by Bjorn Reese 06 Jul '17

06 Jul '17

How would an example of receiving a chunked transfer using the synchronous API look? In pseudo-code, I want to do as follows: establish connection while not closed read chunk print chunk

4 25

Boost Master branch is now closed for the beta
by Marshall Clow 06 Jul '17

06 Jul '17

Except with explicit permission by a release manager. Do whatever you want on develop, just don't change master. We'll re-open master after the beta. -- Marshall Upcoming release schedule: 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 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 -- Marshall

4 3

Fwd: [review][beast] Review of Beast
by Michael Caisse 06 Jul '17

06 Jul '17

I received this review as a private email from Stanislav who has indicated that I may share it on the list. -------- Forwarded Message -------- Subject: [boost] [review][beast] Review of Beast Date: Thu, 6 Jul 2017 20:23:26 +0300 From: Stanislav Karchebnyy <hidden> To: mcaisse-lists(a)ciere.com Good day! I'm not a very good writer in english, so i tried to keep it short and to the point. - What is your evaluation of the design? I believe it fits well with asio style. - What is your evaluation of the implementation? I like the modularity and composability of the library, e.g. various buffers that comply with asio interfaces. Also use of helpful typedefs makes code a lot easier to read. Code style is almost declarative (which is a good sign in my book). - What is your evaluation of the documentation? Documentation is good, although some methods are documented a little short and a bit tautologically. This is not specific to beast however, seen it in many other boost libraries. - What is your evaluation of the potential usefulness of the library? It is immensely useful as it is already. See below for the example. - Did you try to use the library? With which compiler(s)? Did you have any problems? Currently I’m developing with Beast on latest OSX with clang. It compiles cleanly and runs quite well. The aim is to later use it also on Linux with gcc. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I’m in process of converting our POCO-based networking code for HTTP/HTTPS client and Websocket client to Beast. I started with Websocket and it was a pleasant and rather quick conversion from POCO-style ActiveDispatcher methods (which are ugly with binds and tuples for argument packs) to truly asynchronous beast websocket implementation. We use own protocol running on top of websocket frames, and with beast it was really easy to implement. That beast is a construction framework and does not have unnecessary boilerplate made it quite easy to plug our own parsing engine directly on top of websocket frames. Code became much cleaner as a result. I did not do speed benchmarking yet, as I’m still in development phase, but I’m much more concerned about maintainability in this project and beast made it a lot better - unfortunately I cannot share the code, but now I can trace the state transitions with a glance, instead of digging through bunch of POCO tuple-ridden methods. Another improvement is the fact that POCO websocket uses a dedicated listener thread for input, while beast utilises proper asio design. Beast comes with quite good examples, that covered about 90% of my questions during transition, the rest was answered by Vinnie himself. He is very responsive and helpful as a library maintainer. - Are you knowledgeable about the problem domain? Yes, I know how http and websocket things are supposed to work. My overall impression with the library and its author helpfulness suggests that ACCEPT to boost is a reasonable move. -- Sr. Software Engineer twilio <http://www.twilio.com/?utm_source=email_signature> EMAIL hidden

1 0

[beast] Response alias?
by Bjorn Reese 06 Jul '17

06 Jul '17

Is it possible to provide a HTTP 200 response alias for Beast? This is needed for SHOUTcast internet radio servers. See for instance: https://curl.haxx.se/libcurl/c/CURLOPT_HTTP200ALIASES.html

2 1

string_view versus string_ref
by Andrzej Krzemienski 06 Jul '17

06 Jul '17

Hi Everyone, I would like to understand the situation with these two templates: basic_string_view and basic_string_ref. The official, advertised library is string_ref: http://www.boost.org/doc/libs/1_64_0/libs/utility/doc/html/string_ref.html At the same time we have string_view: http://www.boost.org/doc/libs/1_64_0/boost/utility/string_view.hpp But the latter is never mentioned in the documentation, except in Boost.Log: (see http://www.boost.org/users/history/version_1_61_0.html) The support for boost::basic_string_ref and its specializations is > deprecated; users are encouraged to switch to boost::basic_string_view. > The support for boost::basic_string_ref will be removed in future > releases. > My question: is there any official position of Boost about having these two templates? Regards, &rzej;

4 3

[beast] Looking for ongoing Code Review!
by Vinnie Falco 05 Jul '17

05 Jul '17

Time for a realistic self-assessment. The feedback that I've gotten about Beast thus far has been pretty great, thanks to everyone for taking the time to get familiar with it. Seems like people are overall approving of the technical quality, but there is a recurring theme with the complaints. Specifically that there are small quality of life issues and deviations from best practices. For example, the two-phase initialization, missing verification on SSL client, verbose or missing examples, confusing or missing parts of documentation. Someone suggested that I solicit assistance from the list. I would like to have ongoing code review of everything in Beast before it gets merged. It would benefit the library greatly and thus benefit its users. As new features get developed ("in-scope" items such as file_body) having an extra set of eyes to make sure I don't do something silly or obviously unpleasant would be helpful. This also reduces the possibility that a future version of Beast may require a breaking change. I'm looking for volunteers to provide regular ongoing code review of branches in Beast's pull request queue! I realize this is a big ask, especially because I have a knack for producing quite a bit of code and change over time. Still, its worth asking. Ideally this review will come from stakeholders (i.e. users of the library). Any Beast users who are out there, please consider participating in code reviews. Its easy just subscribe to the repository using the button on the right of its GitHub page and then when you see new pull requests jump in there and add comments on anything you love/hate. I'll take whatever I can get though, so anyone is welcome! Email me if you want to discuss it, <vinnie.falco(a)gmail.com> or just open an issue on the repository: <https://github.com/vinniefalco/Beast> Thanks! |

1 0

[beast] Platform proxy settings, SSL verification
by Phil Endecott 05 Jul '17

05 Jul '17

Here are just a few quick comments re Beast: 1. It's a terrible name, but I believe others have already mentioned that. 2. I don't believe there is any integration with platform proxy settings. I'll explain: I have my own basic HTTP client and server code that I've used in a handful of projects. There are a few features that it lacks that have caused me problems. In particular, when I tried to use my HTTP client code in an iOS app, it worked on WiFi networks but not on some cellular networks. After much remote debugging I realised that some cellular carriers in some countries require that HTTP traffic goes via a (non-transparent) proxy. If you use the iOS http client then this is handled for you, but my code knows nothing about it. For me to test a fix for this I would have had to fly to another continent.... This is the sort of thing that is particularly valuable in a Boost library: I try to write portable code, but I don't know the details of every platform that it will run on or even have test systems available to me. Having a library that knows about the platform-specific details, and which has been tested on a wide variety of those platforms, is very valuable. (And a library that instead just does the "easy parts" is something that I could have written, or already have written, myself.) 3. Finally a comment about the SSL example at https://github.com/vinniefalco/Beast/blob/master/example/http-client-ssl/ht… This says stream.set_verify_mode(ssl::verify_none); Please correct me if I'm wrong, but I think that means that it does not do any sort of certificate verification. As a matter of principle, I think that the *first* SSL example should show how to establish a properly-secure connection. See for example http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf (""The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software") and e.g. https://lwn.net/Articles/522111/ for discussion. A quick look at http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/overview/ssl.html suggests that this might add as few as two more lines to the code. Regards, Phil.

2 4

[release] Release notes for 1.65.0 beta
by Daniel James 05 Jul '17

05 Jul '17

Hi, If you haven't done so yet, please write your release notes for 1.65.0 beta. You can create a pull request at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_65_0.q… Or if you'd rather you can send them to me, and I'll add them for you. thanks, Daniel

1 0

[build] header-only lib need dir 'build'?
by Oliver Kowalke 05 Jul '17

05 Jul '17

Hi, does a header-only library require sub-directory 'build' (especially if the lib depends on another, non-header-only library)? In other words; is it safe to remove sub-directory 'build' from boost.coroutine2? thx, Oliver

2 2

[beast] write_some EWOULDBLOCK/EAGAIN error recovery non-blocking operations
by Artyom Beilis 04 Jul '17

04 Jul '17

Have been Beast tested with non blocking sockets? I hadn't found a single reference to asio's non_blocking_io? One of the common use cases is when I want to push a small message to stream (chunk). In 99% of cases the operation will not block so I want to handle this as an optimization for not returning to even loop and creating a callback. According to the reference I didn't find how write_some will behave? I expect to get EWOULDBLOCK kind of error and start asynchronous operation. However I didn't find any reference to the code to non_blocking_io so I wonder if it is supported at all. On same note - how do I run unit tests using b2 - Beast ins't fully Boostified which BTW is also bothering me. Artyom

4 6

[xpressive] Merge PR for fixing MSVC 14.1
by Andrey Semashev 04 Jul '17

04 Jul '17

Hi, There is this PR from Daniela Engert to fix Boost.Xpressive compilation failure with MSVC 14.1: https://github.com/boostorg/xpressive/pull/4 It replaces the removed std::unary_function with the equivalent typedefs. The change looks rather harmless. Could this PR be merged before 1.65 is out? Thanks.

1 1

[iterator][range] BoostIteratorTraversalConcepts-aware boost::advance/distance
by Michel Morin 04 Jul '17

04 Jul '17

Hi, The Boost iterator traversal concepts have not been adopted by the C++ Standard. Because of this, some of RandomAccessTraversalIterators (Boost's concepts) are treated as InputIterators (Standard's concepts) by the stdlib. IMHO, Boost.Iterator should provide BoostIteratorTraversalConcepts-aware `boost::advance` and `boost::distance` to avoid the inefficiencies. However, neither of them are implemented. (Boost.Range has `boost::distance` for ranges, but it just calls `std::distance`.) I'm attaching files that implement `boost::advance` and `boost::distance`. Would these functions be useful additions? Regards, Michel

4 13

[beast] Review
by Peter Dimov 04 Jul '17

04 Jul '17

This is my review of the Beast library. I. DESIGN --------- The design of the library is very good and appears mature. The concepts are well specified, well documented, well thought out. The use of concept checks is a nice touch and a mark of professionalism. I think that basing the library on ASIO (resp. the Networking TS) is a fine decision. This does mean that if one finds an ASIO/NetTS concept less than ideal, one has to live with it, but that's an acceptable tradeoff. Severing the ties with ASIO based on the yet-hypothetical "structured blobs in, structured blobs out" model may sound good in theory, but in practice, a supermajority of the potential users of Beast need to produce a working HTTP or Websocket server, and the library as it stands addresses this need. The design is not perfect; at times the library makes it much too easy for asymptomatic mistakes to be introduced by the omission of a required member function call. For example, if one forgets to set the Content-Length, everything will still appear to work; or if one forgets to initialize the .result of the response, it remains uninitialized. (Note that these, and subsequent, observations appertain to the library as submitted for review; they may no longer be relevant since the author is very quick with the fixes.) There is, at times, unnecessary verbosity, even in the two storefront examples in http://vinniefalco.github.io/stage/beast/review/beast/quick_start.html that are supposed to show the library in the best possible light. For instance, // Set up an HTTP GET request message http::request<http::string_body> req; req.method(http::verb::get); req.target("/"); req.version = 11; Every request will need a method and a target, so having to call members to set them feels unnecessary. A constructor ought to have been provided. Similarly, in the next example, // WebSocket says that to close a connection you have // to keep reading messages until you receive a close frame. // Beast delivers the close frame as an error from read. // beast::drain_buffer drain; // Throws everything away efficiently for(;;) { // Keep reading messages... ws.read(drain, ec); // ...until we get the special error code if(ec == websocket::error::closed) break; // Some other error occurred, report it and exit. if(ec) return fail("close", ec); } the drain loop is basically a requirement for every correct program, so it should have been encapsulated into a helper function. (Even though the example as written does illustrate the use of a drain_buffer.) I'm not particularly fond of the design decision to declare parts that in practice every user of the library will need as "out of scope". People should not be made to reinvent these wheels. I understand the aim of producing a standard library proposal, and that some of these wheels would not be suitable for standardization, but there's nothing easier than just including the suitable wheels in the formal proposal and omitting the unsuitable ones. In practice, these necessary parts end up as examples, so one has to #include "../example/wheel.hpp" instead of "beast/wheel.hpp". It would be better, in my opinion, if one includes, say, "beast/ext/wheel.hpp", with it being known that ext/ is where "out of scope" things go. The ASIO coupling did leave me with one question, whether it would be possible for the library to accommodate OS-specific file to socket transfers such as the one provided by TransmitFile: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).… The idea here is that the OS kernel can dump the file to the socket without involving user mode, which has the potential of much increased performance. For the median user, this would not make much of a difference, but it's an interesting design question, and perhaps an argument that the example file_body class ought to be part of the library proper. ("Is in scope", to use the preferred terminology.) II. IMPLEMENTATION ------------------ I did not pay close attention to the implementation. A random sampling reveals that it's professionally written, and it appears to work, which is good enough for me. The tests run when `b2` is invoked in `test`, have good coverage, and pass with MSVC 14.0 and 14.1. Travis/Appveyor are put to good use. The library provides a doc/Jamfile, which is a plus, but this Jamfile fails, which is a minus. The file reference.qbk has its own separate build script, and this would need to be fixed one way or another when the library is integrated into the Boost documentation build. III. DOCUMENTATION ------------------ The documentation is good. The non-reference parts are very good, the examples are informative. The reference is very good at times, and not so much at others. This is caused by the fact that to get to the good parts one needs to drill down a level or two. For instance, looking at http://vinniefalco.github.io/stage/beast/review/beast/quickref.html I noticed the "async_teardown" function in the WebSocket section, so I clicked on it to see if I need to call that to tear down a WebSocket connection. This lead me to http://vinniefalco.github.io/stage/beast/review/beast/ref/beast__websocket_… which only says "Start tearing down a boost::asio::ssl::stream/connection/boost::asio::ip::tcp::socket." Googling told me that I'm not the only one left not entirely satisfied with these descriptions: https://github.com/vinniefalco/Beast/issues/274 The confusion here stems from the fact that would I, and the issue submitter, have clicked on one of the async_teardowns in that page, we would have reached f.ex. http://vinniefalco.github.io/stage/beast/review/beast/ref/beast__websocket_… which is indeed fine, and mentions that the implementation calls this function, not the user. This is a general pattern with the reference. The leaves are perfectly fine, but the upper levels are often uninformative. IV. PRACTICAL USE ----------------- As part of conducting this review, I ported two existing servers of mine to Beast, one HTTP, one WebSocket. The HTTP server can be seen at https://github.com/pdimov/beast_tpc_server and the WebSocket one is at https://github.com/pdimov/beast_ws_async_server The experience was pleasant and things went more or less as expected, with virtually no nasty surprises. The author was very helpful. The library proper worked exactly as advertised, and the servers were both easier to write than the originals, and became more robust. I only wish that more out of scope things (target parser, basic authorization handling) become in-scope, because their absence is being felt. V. VERDICT ---------- Beast should be ACCEPTED. It's useful, it works, it serves a legitimate need, and I see no design or implementation problems that would preclude acceptance.

2 1

[gil::io] Compilation issue
by Christian Henning 04 Jul '17

04 Jul '17

Hi all, my metaprogramming zen is failing me and I like to ask for some help. Using gil's updated develop branch the following code creates a compilation error with Visual Studio 2015 Update 3. #include <boost/gil/extension/io/tiff_all.hpp> using namespace std; using namespace boost; using namespace gil; int main() { gray1_image_t img; write_view( "", view( img ), tiff_tag() ); return 0; } The compiler output is here: https://pastebin.com/raw/d1AB9QMz I think the error is in https://github.com/boostorg/gil/blob/develop/include/boost/gil/premultiply.… but I'm not sure what to do. Any help would be very helpful! Thanks, Christian

1 1

[Beast] Review
by Artyom Beilis 03 Jul '17

03 Jul '17

Hello, This is my formal review of Boost Beast. > What is your evaluation of the design? Also the general design is solid provides generic API that does the job it defined. The most problematic issue with Beast is it total reliance on static polymorphism. This comes to sometimes very painful issues like: Having the object code duplicated for different variants HTTP/HTTPS code Having all the implementation in headers increasing compilation time Adding complexity to end user since he needs to propagate the templates to various places. Virtually all concepts could be done with classic interfaces and virtual functions. Using of static polymorphism does not provide there performance advantage but reduces code maintainability and adds lots of headache to end user. Note: it does not contradict of using ASIO but lots of stuff could be pimpled or hidden having only few forward declarations of the relevant classes. > What is your evaluation of the implementation? >From what I seen didn't find may flows besides thous mentioned before (content-length - that was fixed) and non-blocking sockets aren't covered by tests. However I didn't look too much since the code is quite hard to read being too template heavy. Second major issue is that it puts all the heavy work on end user providing tiny parsing messaging layer that to be honest is the simple part of HTTP handing. It significantly limits its usability to virtually void. > What is your evaluation of the documentation? Documentation is OK - similar to ASIO - I think more examples should be needed and tutorials regarding how to do common tasks. > What is your evaluation of the potential usefulness of the library? VERY limited. The library does too little to be useful for real development. I don't really see a real need for a library that could potentially be used to create CURL or could potentially be used to write web framework that users will work over them. As a user of this library you need to deal with: - User has to have deep knowledge of HTTP protocol itself and be highly aware of various security related problems on WWW. - Protocol itself and know it up to the small details, timeouts and much more. - Being able to parse all parameters passed from getting query string, parsing multipart/form-data (a.k.a. file upload format) parse percent encoding, cookies. I suggest to drawing the line at some point when library becomes useful for somebody who for examples needs to implement RESTful service or send some post data to a form. The separation line that was drawn does not suite the needs of too many of potential users. I understand it is huge task to do but if first lines in your FAQ and many other talk about what the library doesn't do than probably something goes wrong. And please note I don't talk about sessions, url mapping, but much more basic stuff like multipart parsing, url-encoding. URL parsing, > Did you try to use the library? With which compiler(s)? Did you have any problems? Tried to compile several examples no problem. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? At least 10-12 hours of reading documentation, code, running some examples. Notifying potential problems. > Are you knowledgeable about the problem domain? Yes, I'm myself an author of CppCMS C++ Web Framework - fully featured web development platform for C++ that works in both synchronous and asynchronous modes, I implemented HTTP and FastCGI protocols, networking engines myself. Designed high performance services and more. > Should the library be included to Boost? Unfortunately NO. Two major reasons: - Abuse of static polymorphism where classing object oriented design with virtual functions can do better job. - The scope of the library is way too limited that it brings the question of its usability for real users. I fully acknowledge the huge high quality work the author did - something that kept me reviewing the library and providing the comments, but the library as it is today IMHO doesn't suit Boost Best Regards and Good Luck, Artyom Beilis

1 0

[Beast] HTTP/1.0 Protocol compatibility
by Artyom Beilis 03 Jul '17

03 Jul '17

I can't find there an (sami)automatic way to manage HTTP/1.0 vs HTTP/1.1 compatibility? Example I have a client that supports HTTP/1.0 only and I need to transfer an unknown amount of data. Now as one who writes the server I need to check the clients protocol and choose chucked transfer encoding with possibility to keep connection keep alive or close one after data transfer using socket shutdown. Shouldn't this kind of stuff should be handled automatically or sami-automatically? Keep alive semantics between HTTP/1.0 and HTTP/1.1 is tricky and it is very easy to make a mistake. Also note I tested some of your examples and found that they responding with HTTP/1.1 on HTTP/1.0 requests. Artyom

2 1

[property_tree] Is Boost.Property_tree maintaner active?
by Александр Зайцев 03 Jul '17

03 Jul '17

Hello. I see on Boost.Property_tree's Github repo a lot of PR. And I want to know, is maintainer active or not.

1 0

[beast] Asynchronous examples
by Phil Endecott 03 Jul '17

03 Jul '17

Hi, Do any of the Beast examples show its use in asynchronous mode? I'm wondering how difficult it is to achieve this: future< vector< byte > > data = download(url); Regards, Phil.

2 2

[beast] thread per connection example?
by Peter Dimov 02 Jul '17

02 Jul '17

Suppose that I want to implement an HTTP server that uses the thread per connection model. What example should I use as a starting point?

2 2

[beast] Wy does message<> store Body::value_type?
by Peter Dimov 02 Jul '17

02 Jul '17

Why does message<isRequest, Body, Fields> store Body::value_type, using Body::reader and Body::writer to manipulate it, instead of the more straightforward approach of storing Body, which would have allowed making `get` and `put` members of the Body directly, instead of using intermediate classes?

3 3

[beast] Automatic content-length?
by Peter Dimov 02 Jul '17

02 Jul '17

In this code, extracted from one of the examples in the documentation, // Set up the response, starting with the common fields response<string_body> res; res.version = 11; res.set(field::server, "test"); /*...*/ // We return responses indicating an error if // we do not recognize the request method. res.result(status::bad_request); res.set(field::content_type, "text/plain"); res.body = "Invalid request-method '" + req.method_string().to_string() + "'"; // Send the response write(stream, res, ec); field::content_length isn't set. Will Beast insert Content-Length based on the body size, or will it send the response with the field missing? The reason I ask is that I foresee forgetting the content_length to be a common mistake, and an asymptomatic one.

2 7

[beast] socket versus stream
by Bjorn Reese 02 Jul '17

02 Jul '17

The HTTP API provides a set of free function for all operations, so all interaction follows this pattern: operation(socket, args); The WebSocket API wraps an Asio socket in a stream, so all operations are like this: stream.operation(args); I realize that the latter choice is a consequence of using SSL, but I am wondering why there is no socket.operation(args) style for the former?

2 1

[gil::io] Dependent Name issue with VS2015 Update3
by Christian Henning 01 Jul '17

01 Jul '17

Hi all, using the new gil::io on gil's develop branch I get a compilation error with Visual Studio 2015 Update 3. When trying to read a tiff image: #include <string> #include <boost\gil\gil_all.hpp> #include <boost\gil\extension\io\tiff_all.hpp> using namespace std; using namespace boost::gil; int main() { rgba8_image_t img; read_image( string(), img, tiff_tag() ); return 0; } I get an error: error C2951: template declarations are only permitted at global, namespace, or class scope The problem seems to be with https://github.com/boostorg/gil/blob/develop/include/boost/gil/extension/io… Can someone please tell me if my issue is a compiler issue or simply a syntax error. Thanks, Christian

3 3

Re: [boost] [Beast] Questions Before Review
by Artyom Beilis 01 Jul '17

01 Jul '17

http vs WebSocket -------------------------- I noticed some strange difference in these requests : // Wrap the now-connected socket in a websocket stream websocket::stream<tcp::socket&> ws{sock}; // Perform the websocket handhskae ws.handshake(host, "/", ec); if(ec) return fail("handshake", ec); This one is fast and easy to use does all it needed Now HTTP is very different story http::request<http::string_body> req; req.method(http::verb::get); req.target("/"); req.version = 11; req.set(http::field::host, host + ":" + std::to_string(sock.remote_endpoint().port())); req.set(http::field::user_agent, BEAST_VERSION_STRING); req.prepare_payload(); Most of stuff can be defined there by default: version 1.1, Host header - required by http/1.1 why should I bother? User agent put one by default unless user wants - you do all this stuff for WS handshake so why not there? Why so complicated? ----------------- Protocol Premier HTTP/1.1 example without host. Your example isn't valid HTTP /1.1 request. HTTP /1.1 unlike 1.0 requires host header Artyom

2 4

[Beast] Security issue note
by Artyom Beilis 01 Jul '17

01 Jul '17

Looking into parser/body code I noticed: parser: void on_body(boost::optional< std::uint64_t> const& content_length, error_code& ec) { wr_.emplace(m_); wr_->init(content_length, ec); } string_body: void init(boost::optional< std::uint64_t> content_length, error_code& ec) { if(content_length) { if(*content_length > (std::numeric_limits< std::size_t>::max)()) { ec = make_error_code( errc::not_enough_memory); return; } ec.assign(0, ec.category()); body_.reserve(static_cast< std::size_t>(*content_length)); } } Basically I can exhaust the memory of the server and kill it by providing huge content length from several connections and lead to its crash. Reasonable and configurable limit should be provided for content length. Artyom Beilis

2 6

[Beast] Questions Before Review
by Artyom Beilis 01 Jul '17

01 Jul '17

Hello Vinnie Falco, I have several design questions regarding this library before the review. DISCLIMER: My name is Artyom Beilis. I'm the author of CppCMS C++ Web Framework: http://cppcms.com It may seems like it can be in some competition with Beast but I don't see it this way as Beast is too low level library that does not addresses typical problems of developers needing Web API/Site running using C++. CppCMS addresses totally different problems in different way. So there are my design related questions: Header Only Design --------------------------- As somebody who worked with guys who do web development, it was very clear that compilation time is an issue. A simple build of http_server_small.cpp example requires about 6s(!) of compilation time g++ 5.4 http_server_fast.cpp takes 7s In comparison entire message board containing templates code flow SQL and more leads to only 4s - non paralel build. (https://github.com/artyom-beilis/cppcms/tree/master/examples/message_board ) I understand that you work on base of Boost.Asio - which itself has unacceptable compilation times but having for web application development may be serious deal breaker for big projects. Which Leads me to another design Choice Template Meta-programming Based Design instead of classic Object Oriented Design ---------------------------------------------------------------------------------------------------------------- I see that almost every object there is some kind of template object. It almost mimics the API of Boost.Asio which on its way has its limitations. I remember I needed to implement FastCGI over TCP and Unix domain sockets virtually leading to same code besides some initial bind - and it required to create the entire parser using template programming because the socket itself was template object different for UNIX and TCP. I have strong feeling that lots of stuff can actually be done using classic OOP. Example Question: > Can I implement same server code for both SSL and non SSL HTTP protocol > without use of templates in the class itself? And my current final question Who are the potential users of the library? ------------------------------------------------------- If I need to send a simple http request to server it does not seem to do simple enough job (see your FAQ) so I'll probably be better with feature rich libcurl. If I need to implement complex web server/service I don't have cookies, sessions, forms, html? If I need to implement RESTful API do I have all stuff like URL mapping of different paths to callbacks, protocol abstraction http/https (basic stuff - I don't see it there correct me if I wrong) Is it for web server developers? Maybe I'd be happier with simple HTTP protocol parser that I can integrate to any socket API? Can you please give more accurate description of who is this library intended for? Best Regards, Artyom Beilis

5 21

Follow-up to the CMake follow-up
by Peter Dimov 01 Jul '17

01 Jul '17

Due to the strong interest in my previous follow-up, I'm following it up with a more complete implementation of the support required for CMake scenario #1, installing configuration files during "b2 install" such that subsequent "find_package" calls work (assuming a suitably set CMAKE_PREFIX_PATH). You can find it in branch "feature/install-cmake-config" in the superproject (boostorg/boost). In other words, git clone --recursive --depth 64 -b feature/install-cmake-config https://githib.com/boostorg/boost bootstrap b2 headers b2 install cmake//install variant=debug,release link=static,shared runtime-link=static,shared This doesn't yet support installation with more than one toolset, and I'm sure that some libraries don't work, but a simple test using Filesystem and ProgramOptions does. /// CMakeLists.txt: /// cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) list(APPEND CMAKE_PREFIX_PATH C:/Boost) find_package(boost_filesystem 1.63.0) find_package(boost_program_options 1.63.0) # disable autolink globally # could also do it per-target add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::filesystem boost::program_options) /// cmake_demo.cpp: /// #include <boost/filesystem.hpp> #include <boost/program_options.hpp> #include <cerrno> #include <iostream> namespace fs = boost::filesystem; namespace po = boost::program_options; int main( int argc, char const* argv[] ) { po::options_description desc( "Allowed options" ); desc.add_options() ( "help,h", "produce help message" ) ( "path,p", po::value<std::string>(), "set initial path" ) ; po::variables_map vm; try { po::store( po::parse_command_line( argc, argv, desc ), vm ); po::notify( vm ); } catch( std::exception const & x ) { std::cerr << "Error: " << x.what() << std::endl; return 1; } if( vm.count( "help" ) ) { std::cout << desc << std::endl; return 1; } fs::path p = fs::current_path(); if( vm.count( "path" ) ) { p = vm[ "path" ].as<std::string>(); } std::cout << p << std::endl; }

2 1

Does Boost 1.64 support HP-UX?
by 장윤진 30 Jun '17

30 Jun '17

I read about the platform that boost supports on the boost homepage. However, I do not know if it supports HP-UX. http://www.boost.org/doc/libs/1_64_0/libs/log/doc/html/log/installation.htm… Supported compilers and platforms. The library should build and work with a reasonably compliant compiler. The library was successfully built and tested on the following platforms: Windows XP, Windows Vista, Windows 7. MSVC 8.0 SP1, MSVC 9.0 and newer. Linux. GCC 4.5 and newer. Older versions may work too, but it was not tested. Linux. Intel C++ 13.1.0.146 Build 20130121. Linux. Clang 3.2. Does that mean it supports HP-UX?

3 2

Noexcept
by Emil Dotchevski 30 Jun '17

30 Jun '17

The lively debates during the Outcome review show that there is a great deal of interest in solving the problem of error handling in environments where C++ exception handling is unavailable. Noexcept is a new C++11 library that implements a different approach to solving the same problem. Any feedback is welcome. https://zajo.github.io/boost-noexcept/ Emil

12 81

[review] Mp11 review starts in two weeks
by Bjorn Reese 29 Jun '17

29 Jun '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11 [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

CMake followup
by Peter Dimov 29 Jun '17

29 Jun '17

In a previous post I identified several scenarios for CMake support, where number one was 1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname). For this, I said "The changes to the `b2 install` procedure significantly exceed my bjam-fu however, so if we decide to proceed with this - and I don't see how we could claim CMake support in a meaningful way without it - the interested parties would need to figure out a way to make that happen." but I lied. (Well, not entirely, I had a lot of help.) Here https://github.com/pdimov/boost-cmake-demo is a proof-of-concept implementation that more or less works for our beloved test case of Boost.System. To test (the instructions are for Windows, where I tested), clone the repo, do b2 headers b2 --build-type=complete install as usual, then b2 cmake//install variant=debug,release link=static,shared runtime-link=shared (or whatever combination of options you prefer.) This should install -config.cmake files into $prefix/libs/cmake. Then, in a CMakeLists.txt, cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) #set(BOOST_BUILD_VARIANT RELEASE) #set(BOOST_LINK_TYPE SHARED) #set(BOOST_RUNTIME_LINK STATIC) find_package(boost_core 1.63.0) find_package(boost_system 1.63.0) # disable autolink globally # could also do it per-target add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::core boost::system) or similar. Ideally, cmake//install would be integrated into the install target (and cmake//stage into stage, respectively.)

1 0

[iterator][utility] Move utility/next_prior.hpp to Iterator module?
by Michel Morin 29 Jun '17

29 Jun '17

Andrzej Krzemienski wrote: >> Do you mean coupling of Boost.Iterator and Boost.Range? I think that would >> be fine, since Boost.Range already couples with Boost.Iterator. >> Boost.Range's `boost::distance` should call Boost.Iterator's >> `boost::distance`. >> > > I meant `next()` and `prior()` that are located in Utility: > http://www.boost.org/doc/libs/1_64_0/libs/utility/utility.htm Ah ok, got it. I think it would be better to move utility/next_prior.hpp to the Boost.Iterator module. After the move, the Boost.Iterator module will have: - include/boost/iterator/next_prior.hpp * Contains the actual code for `next` and `prior`. (Personally, I'd like to add `boost::prev` as a synonym of `boost::prior`.) - include/boost/utility/next_prior.hpp * Just includes <boost/iterator/next_prior.hpp>. This is how utility/declval.hpp was moved to the Boost.TypeTraits module. Regards, Michel

1 0

[beast] Formal "review" branch frozen
by Vinnie Falco 29 Jun '17

29 Jun '17

The "review" branch of Beast is now available and frozen for modifications. It contains the snapshot of the repository which will undergo the Boost formal review starting on July 1 and lasting for 10 days. Currently the review branch is even with the master branch, at version 70. The review branch repository is here: https://github.com/vinniefalco/Beast/tree/review The review documentation snapshot: http://vinniefalco.github.io/stage/beast/review/ Autobahn WebSocket Implementation Test Report: http://vinniefalco.github.io/autobahn/index.html Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocolvocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. Beast empowers users to create their own libraries, clients, and servers using HTTP/1 and WebSocket. Code will be easier and faster to implement, understand, and maintain, because Beast takes care of the low-level protocol details. Please don't forget to "star" the repository on GitHub, the increased exposure will vitalize Beast and Boost with the new generation of programmers! Thanks! -- Follow me on Github: https://github.com/vinniefalco

1 0

Boost MSM attribute sharing problem
by Christophe Henry 28 Jun '17

28 Jun '17

>Hello everyone, > >I have an issue with* Boost MSM*. >Using *Boost MSM eUML* I have created a >state machine. Actually I created *HSM* (Hierarchical State Machine) or >Composite State Machine as second name. >And I faced with issue: How to >share attributes between Parent State Machine and Sub-State Machines >(or Child State Machine) ?? > >I have not found an answer on this question ... >Could anyone possibly help me ? > >*Thanks,* > >*Best RegardsDenis Kotov* Hi Denis, I think the best way is to have your attributes owned by the top-level state machine, then passed to the composite as say, a pointer. The top-level can call get_state, then set the attribute. For example, with eUML, supposing you declared the attribute with BOOST_MSM_EUML_DECLARE_ATTRIBUTE (or without for other front-ends): get_state<Composite&>().get_attribute(some_attribute) = &top_attribute; HTH, Christophe

1 0

Boost.Build and Microsoft C2 clang
by Niall Douglas 28 Jun '17

28 Jun '17

Can someone who has this working right please tell me how they persuaded Boost.Build to correctly invoke Microsoft C2 clang as the compiler and get it to link properly? My GSoC student has tried: - Configuring clang-win, this is a no-go, C2 clang comes in GCC arguments accepting form, not MSVC arguments accepting form. And no there is no clang-cl program supplied by Microsoft. - Configuring mingw gcc but with the C2 clang executable, this compiles code okay but fails at the link stage for some reason, probably it's trying to invoke the mingw linker and we want the Microsoft linker. Any help much appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 17

[thread] Interaction between interruption points and condition_variable
by David Stone 28 Jun '17

28 Jun '17

Assume 1) A thread is waiting on a condition_variable 2) That condition_variable has been notified that its condition is now true 3) The thread has been interrupted Given this, the interruption is processed rather than the condition_variable unblocking normally regardless of the order in which the notify and the interruption occur. That means that this program would eventually fail even though the notify always comes before the interrupt. #include <boost/thread/condition_variable.hpp> #include <boost/thread/lock_types.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/thread.hpp> #include <cassert> struct flag_t { using lock_type = boost::unique_lock<boost::mutex>; void notify() { auto lock = lock_type(m_mutex); m_flag = true; m_cv.notify_one(); } void wait() { auto lock = lock_type(m_mutex); m_cv.wait(lock, [=]{ return m_flag; }); } private: bool m_flag = false; boost::mutex m_mutex; boost::condition_variable m_cv; }; struct test_t { unsigned value = 0; ~test_t() { assert(value != 0); assert(value != 1); assert(value == 2); } }; int main() { while (true) { flag_t flag; test_t test; auto thread = boost::thread([&]{ test.value = 1; boost::this_thread::interruption_requested(); flag.wait(); test.value = 2; }); flag.notify(); thread.interrupt(); thread.join(); } } If we move the `flag.notify()` line before the thread creation, this program never terminates. This is because `boost::condition_variable::wait(lock_type &, function)` is defined as only blocking when the function returns false. The only way this program can terminate is if `thread` begins execution and executes `flag.wait()` before `flag.notify()` is called, then `thread.interrupt()` runs before `thread` is unblocked. It seems more intuitive to me that if a thread is blocked on a condition_variable and it is interrupted that it would unblock normally rather than throwing boost::thread_interrupted. Under that behavior, users who want the current behavior can always check after they leave a condition_variable::wait using `boost::this_thread::interruption_requested()` and throw rather than processing data. Under the current behavior, I do not believe there is any way to process the data in a function that does not have access to the thread object without losing the fact that an interruption was requested. This would only be possible if we had a function like `boost::this_thread::interrupt()`, but that does not exist. I do not know what code (if any) depends on the current behavior of interruptions always taking precedence over notifications, but it appears that the current behavior is undocumented. Is there a justification for the current behavior or is it just the way it happened to be implemented? Is this something we could change, or at least allow users to implement the behavior I outlined?

3 5

Reminder: 1.65 closes for major changes tomorrow
by Marshall Clow 28 Jun '17

28 Jun '17

Upcoming release dates: 28-Jun: Boost 1.65.0 closed for major changes 5-Jul: Boost 1.65.0 closed for all changes, except by permission of a release manager. 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 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 -- Marshall

6 12

Testing for ML Admin
by Alexander Zaitsev 28 Jun '17

28 Jun '17

Hello. Â I am simple letter and i want to be a part of boost mailing list. Â Hey, see - i have body. Head and body. Â --Â Best regards, Alexander Zaitsev Â

1 0

[sort] pdqsort mini-review
by Александр Зайцев 27 Jun '17

27 Jun '17

Hello. Try to send my thoughts from another email. 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort? 1. Only that pdqsort is really better than std::sort's Introsort 2. Yes, it does. 3. Pdqsort is much faster than std::sort. 4. Yes, i do. I think that pdqsort is really good sort algorithm - it's really fast and pdqsort is already implemented sort algorithm in Rust's libcore as sort_unstable. 5. No, i have not. Best regards, Alexander Zaitsev zamazan4ik(a)gmail.com

1 0

[sort] pdqsort mini-review
by Александр Зайцев 27 Jun '17

27 Jun '17

Hello. Try to send my thoughts from another email. 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort? 1. Only that pdqsort is really better than std::sort's Introsort 2. Yes, it does. 3. Pdqsort is much faster than std::sort. 4. Yes, i do. I think that pdqsort is really good sort algorithm - it's really fast and pdqsort is already implemented sort algorithm in Rust's libcore as sort_unstable. 5. No, i have not. Best regards, Alexander Zaitsev mazahaka2009(a)list.ru

1 0

Interest in another formatting library ?
by Roberto Hinz 27 Jun '17

27 Jun '17

Hi, Is there space for another formatting library in Boost? Anyone interest in this one? doc: https://robhz786.github.io/stringify/doc/html/index.html code: https://github.com/robhz786/stringify

5 11

Cmake
by Peter Dimov 26 Jun '17

26 Jun '17

There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios: 1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname). 2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them. 3. The user uses CMake to install an individual Boost library, which is then available for find_package. 4. The user uses CTest to run the tests of an individual Boost library. 5. CMake is supported as a way to build and install the entire Boost, in place of b2. 6. CTest is supported as a way to run the tests for the entire Boost, in place of b2. At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck. 5-6 in particular require that all Jamfiles are ported at once, which is a serious undertaking for a questionable benefit as what we have already works. I've done a proof of concept for (2), which can be seen here: https://github.com/pdimov/boost-cmake-demo-2 This repository uses git submodules in ext/ to bring in Boost.System (our guinea pig) and its dependencies, then uses them via add_subdirectory in https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt The required CMake infrastructure is on branch feature/cmake in those six libraries (assert, config, core, predef, system, winapi.) It consists of CMakeLists.txt in the root: https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b6… and supporting .cmake files in cmake/ : https://github.com/boostorg/system/tree/c306d479e8326a68d07ee7f058a415fe8b6… The goal here is for Boost library developers to be able to remain ignorant of CMake if they so choose; so of those files, only sources.cmake requires their input (it's empty for header-only, so those require nothing at all.) BoostVersion.cmake and default.cmake are common for all libraries and are copied from the superproject. dependencies.cmake is automatically generated with boostdep. There is a Jamfile in cmake/ that updates these three files: https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b6… and the intent is for this to be done automatically in a superproject script that invokes "b2 cmake" for the superproject: https://github.com/pdimov/boost-cmake-demo/blob/master/cmake/Jamfile which in turn invokes "b2 cmake" in each library having "cmake/Jamfile". Copying BoostVersion.cmake and default.cmake, instead of referring to them, allows libraries to be used without a superproject, to support scenarios (2) and (3) above. (Scenario (3) is also supported by default.cmake.) What remains to be done is (a) to extend this to the rest of the Boost libraries, if we decide to do so, which would require figuring out a way to cope with the numeric/ irregular libraries, and (b) support for scenario (1) above. Scenario (1), that is, `b2 install` making the installed Boost available for CMake find_package use, is an entirely separate undertaking, completely independent of what I've done - except for possibly reusing the dependencies.cmake files. It would entail generating boost_libname-config.cmake and boost_libname-config-version.cmake files for each library, and boost_libname-config-<suffix>.cmake subconfiguration files for each build variant (toolset, variant=debug/release, link=static/shared, runtime-link=static/shared, runtime-debugging=on/off, threading=single/multi, and possibly python-debugging=on/off.) This would probably require us to define CMake variables controlling these features, such as BOOST_BUILD_TOOLSET, BOOST_BUILD_VARIANT, BOOST_LINK_TYPE, BOOST_RUNTIME_LINK, and so on, with them having appropriate default values inferred from the CMake environment. Then, boost_system-config-vc141-mt-gd-1_65.cmake will check these values and if BOOST_BUILD_TOOLSET is "vc141", BOOST_LINK_TYPE is SHARED, BOOST_RUNTIME_LINK is SHARED and BOOST_RUNTIME_DEBUGGING is ON, it will declare an imported target pointing to boost_system-vc141-mt-gd-1_65.lib/dll, otherwise it would do nothing. (Not sure how relevant is threading=single/multi today, but in principle, it should also check BOOST_THREADING == MULTI.) Generating these -config.cmake files would ideally be done as part of the `b2 install` procedure and require no changes to the individual libraries. The changes to the `b2 install` procedure significantly exceed my bjam-fu however, so if we decide to proceed with this - and I don't see how we could claim CMake support in a meaningful way without it - the interested parties would need to figure out a way to make that happen. At this point, I know what needs to be done, but not how to bring it about.

16 67

Re: [boost] What's wrong with top-posting?
by Brian Wood 26 Jun '17

26 Jun '17

David Abrahams writes: > At Tue, 26 Jan 2010 10:09:43 -0800, > Robert Ramey wrote: >> > > I thought I was familiar with the guidelines and never remembered this. >> >> I top-post all the time. It seems much more natural to me when >> it's not convenient to intersperse comments into the previous >> message. Why I like top posting: >> >> a) It means that I don't have to scroll to the bottom of a message >> which is sometimes pretty long. >> b) To me it is more natural to follow the style >> of other communications (artilcle, books, etc) which make >> their point in the main text and refer to footnotes, bibliographies, >> etc at the end of the main text. > > c) You don't confuse or even *upset* (as I've discovered the hard way) > many people in the business world, where top-posting and > overquoting is the accepted standard. Every message drags along > the entire thread history with it, and you keep a record of > everything by storing the final message. (yuck) It's a cultural > thing, and Boost fits into the open-source programmer weenie > culture much more than the business culture. I was getting annoyed by some top-posting here recently, so I dug up this thread. Is an "open-source programmer weenie culture" like a nerdy culture? Anyway, please stop top posting and trim the old parts of the thread that are no longer needed. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

4 3

[outcome v2] Please comment on new result<T, EC> reference API docs
by Niall Douglas 26 Jun '17

26 Jun '17

Dear Boost, I've been hard at work refactoring Outcome to match the peer review a few weeks ago. Much comment at the time mentioned the poor experience of the reference API docs, so can I get a community check of this: https://dedi4.nedprod.com/static/result-v2/doc_result.html This was generated by the new C++ reference docs generator https://github.com/foonathan/standardese. You'll no doubt spot quite a few formatting bugs, Jonathan says he's onto them. But the usage of libclang rather than doxygen's broken C++ parser clearly shows a lot of benefit, it's just standardese still remains quite a lot short in terms of necessary features to make output fully correct. I won't give the changelog for Outcome v2 result<T> over Outcome v1 yet. Let's see how you fare with the above reference API docs first. But as you'll note, there is considerable change over before as we now slot into a niche not occupied by Expected nor EitherMonad, indeed this now looks much more like Robert's or Lawrence Crowl's slimmed down object. This result<T> is approx 0.6 CPU cycles per stack frame unwound slower which I feel is acceptable in exchange for no more variant storage, which in turn released lots of SFINAE budget for me. (FYI v2 outcome<T> isn't done yet, but it will extend v2 result<T>) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

5 31

[container] includes nonexistent file
by Peter Dimov 25 Jun '17

25 Jun '17

Primary dependencies for container: (unknown): <boost/intrusive/detail/to_raw_pointer.hpp> from <boost/container/detail/to_raw_pointer.hpp> Boostdep says that <boost/intrusive/detail/to_raw_pointer.hpp> doesn't exist, and I indeed don't see it.

2 1

[program_options] behaviour change for implicit options
by Vladimir Prus 25 Jun '17

25 Jun '17

Hi, I have committed, and merged to master, a change making program_option consider subsequent tokens for values of implicit options. For example, if "foo" is implicit option and "bar" is some other option, then: 1. "--foo --bar" will be parsed as option "foo" followed by "bar", and implicit option for "foo" will be used. 2. "--foo bar" will be parsed as option "foo" with the value of "bar" This is the way things worked prior to 1.59, was changed in 1.59, continued to cause confusion, and is now reverted back. For background, see: - http://permalink.gmane.org/gmane.comp.lib.boost.devel/269832 - https://github.com/boostorg/program_options/issues/25 Just in case client code might need to check this behaviour, I've added a feature macro, BOOST_PROGRAM_OPTIONS_IMPLICIT_VALUE_NEXT_TOKEN, which will be set to 1 starting with 1.65. Thanks, Volodya

1 0

Boost MSM attribute sharing problem
by Denis Kotov 25 Jun '17

25 Jun '17

Hello everyone, I have an issue with* Boost MSM*. Using *Boost MSM eUML* I have created a state machine. Actually I created *HSM* (Hierarchical State Machine) or Composite State Machine as second name. And I faced with issue: How to share attributes between Parent State Machine and Sub-State Machines (or Child State Machine) ?? I have not found an answer on this question ... Could anyone possibly help me ? *Thanks,* *Best RegardsDenis Kotov*

1 0

Noexcept improvements
by Emil Dotchevski 25 Jun '17

25 Jun '17

I've completed a second iteration on Noexcept, incorporating valuable feedback from the previous discussions here, and I'd like to thank everyone who participated. https://zajo.github.io/boost-noexcept/ The new result<T> type has a hard value-or-error invariant and can be used to transport errors between threads or to temporarily postpone the consumption of function results, e.g. by storing result<T> objects into a queue (of course, as before, users do not need result<T> just to report a failure from a function.) There is also a new macro, BOOST_NOEXCEPT_CHECK, which makes writing error-neutral functions easier and improves error checking in general. The documentation is also much more complete, including better examples and a new section on programming techniques.

1 0

Fw: [stacktrace] [winapi] header out of place
by Peter Dimov 24 Jun '17

24 Jun '17

The header stacktrace: boost/detail/winapi/capture_stack.hpp should probably either be moved to Winapi, as the name suggests, or renamed to reside in boost/stacktrace/detail. And, as a general rule, libraries should strive to keep their headers under boost/<libname>, with the only exception being boost/<libname>.hpp. We have many legacy libraries not following this requirement, but any new ones and any new headers added to existing ones should. The reason for this requirement is that otherwise it's impossible to perform dependency analysis unless all of Boost is checked out so that the tool can tell in what module boost/random-header-name.hpp resides.

3 2

[review] Boost.Nowide is Accepted into Boost
by Frédéric Bron 24 Jun '17

24 Jun '17

Dear all, I would like to thank all the people who took part in the discussions during the review. All contributors admitted that Boost.Nowide addresses a real issue and solves it, at least partially. Moreover we received 8 official reviews with 6 “accept”, 1 “do not accept as is” and 1 “I am not against it”. So Boost.Nowide is accepted for inclusion in Boost. Congratulation and many thanks to Artyom Beilis for this contribution. However, 2 major issues arose in the discussions and they will have to be fixed before inclusion: 1. handling of ill-formed Unicode input should be improved/clarified 2. the documentation needs improvements In particular, this needs to be fixed: * Design: There was a lot of discussions on what to do with ill-formed UTF-16 strings on Windows, in particular coming from the file system while converting them to narrow UTF-8 strings. Basically, 3 options: 1. allow the roundtrip ill formed UTF-16 > UTF-8 > ill formed UTF-16, this is not possible with UTF-8 encoding, WTF-8 (not a standard) may be an option with some issues 2. issue an error (today’s nowide option, even if the author would like to move to 3.) 3. convert as much as possible to fully conformant UTF-8 with character replacement U+FFFD for invalid input. This is what the NT kernel does with functions like RtlUTF8ToUnicodeN. This would allow cout to continue to work after invalid output instead of failing. After reviewing what was chosen for std::filesystem in C++17, I think 3. is the right think to do: - std::filesystem::path::u8string does not convert strings on Posix. If a conversion is done (on Windows) the output is fully conformant UTF-8. - the roundtrip is not guaranteed in std::filesystem::path conversions (implementation defined) but the roundtrip of a converted paths is guaranteed to work which is the case with Boost.Nowide: once in fully conformant UTF-8, narrow > wide > narrow works fine. - the use of the replacement character U+FFFD is what is done by the NT kernel (question: do you have to reimplement RtlUTF8ToUnicodeN and RtlUnicodeToUTF8N, why not using them)? It should been made clear in the doc that this choice does not guarantees the roundtrip on Windows so that ill-formed filename may not be opened. * Documentation: - the main part of the doc (the non-reference part) should be more detailed - it should be clear to the reader that Windows and Posix platforms are not handled the same; on Windows, we get UTF-8 strings while on Posix platforms, the user should not expect UTF-8 encoding, just narrow strings, even if UTF-8 is today the most common encoding (addressed in Q/A but is probably too far away). It must be clear from the beginning that on Posix platforms, the library does nothing (including no checking of UTF-8 conformance), just forward to the standard library. - review the use of UTF-8 so that it do not let think that narrow strings are always UTF-8 as this is not necessary the case on Posix platform; maybe just use narrow string? - clarify what is converted to what and when: for each function, we need to know precisely what is the output for all possible input; in particular, better explain for each function what the library does with ill-formed input (either UTF-16 input or narrow input), in particular for args and getenv; say clearly what happens (failbit, error, exception, invalid character…) - clarify what is done for Windows and what is (not) done for Posix - explain better what is behind nowide::cout, cin, cerr, what is done? - clarify what does the filesystem integration on Windows vs Posix - check if basic_stackstring::swap needs to swap buffer_ when both strings are on the stack - The doc/ directory is missing a Jamfile, and there's also no meta/libraries.json. * Implementation: - The global BOOST_USE_WINDOWS_H macro should probably be respected. When windows.h is not used, the WinAPI prototypes are declared in the global namespace. This can cause issues when windows.h is also included before/after the Nowide headers, and the prototypes don't match exactly (e.g. short vs. wchar_t). Also it pollutes the global namespace. Nowide should do what other Boost libraries do, and declare the prototypes in a private detail namespace instead. Example in <boost/thread/win32/thread_primitives.hpp>. Need to add a namespace around your definitions. - MinGW gcc: fix warnings in c++03 mode and errors in c++11 and above - Cygwin gcc/clang (errors because of missing ::getenv and friends) - when this is fixed, an error remains: in file included from test\test_system.cpp:11:0: ..\../boost/nowide/cenv.hpp: In function 'int boost::nowide::putenv(char*)': ..\../boost/nowide/cenv.hpp:104:41: warning: comparison between pointer and zero character constant [-Wpointer-compare] while(*key_end!='=' && key_end!='\0') - Under MSYS, one test failed Fail: Error boost::nowide::cin.putback(c) in test_iostream.cpp:17 main - filesystem integration should return somehow the previous locale for potential undoing * Misc: - There are no .travis.yml and appveyor.yml files in the root. - a number of copy/paste references to Boost.System (test/Jamfile) and Boost.Locale (index.html), should be corrected This are just suggestions and are not mandatory for acceptance: - implement stat/opendir/readir - integration with boost::interprocess::file_lock - integration with boost::program_options (in particular for correct line breaks when showing options) Frédéric

3 4

Re: [boost] [review] Review of Nowide (Unicode)
by Groke, Paul 23 Jun '17

23 Jun '17

Hi, this is my official review of the Nowide library. I haven't had much time to look at Nowide, but I have noticed some things that might be of interest, so here we go... > - What is your evaluation of the design? Overall the design looks good. Some things I'd suggest to reconsider: * I'm a big fan of "try" names, so I'd suggest to rename the array versions of widen/narrow to try_widen/try_narrow. Makes it more clear that they can fail without throwing. Also I'm not sure about the benefit of returning the output buffer pointer or NULL. I'd simply return bool instead. * nowide_filesystem... to be honest I'm not sure what this does. If it does something related to UTF-8 on POSIX systems, then I smell a potential problem. If it's only for wide->narrow on Windows, it should be OK. * Also not sure what boost::nowide::cin/cout/cerr do. Do they call SetConsoleCP/SetConsoleOutputCP? Will they work with re-directed input/output streams? What will happen if the user uses them AND std::cin/cout/cerr or stdin/stdout/stderr in the same application? * I'm not a big fan of the basic_stackstring classes. I'd suggest to provide template function overloads for narrow/widen instead. Like: users_favorite::wstring_class wstr; if (boost::nowide::try_widen(wstr, str)) use(wstr); else too_bad(); They could write to the target-string using the usual duck-typing - e.g. via clear/push_back or clear/back_inserter. That way the user can use whatever SSO string class he likes and Nowide wouldn't have to provide string classes -- which IMO isn't its job. As a bonus, the user also gets an exception-free (except bad_alloc) function that doesn't require him to provide a raw array output buffer. * The Windows & invalid UTF-16 thing... I still think invalid UTF-16 should round-trip. > - What is your evaluation of the implementation? Haven't had much time to check the implementation. What I did notice is that when windows.h is not used, the WinAPI prototypes are declared in the global namespace. This can cause issues when windows.h is also included before/after the Nowide headers, and the prototypes don't match exactly (e.g. short vs. wchar_t). Also it pollutes the global namespace. I think Nowide should do what other Boost libraries do, and declare the prototypes in a private detail namespace instead. > - What is your evaluation of the documentation? Incomplete. Too few examples and the reference documentation leaves many things unclear. IMO the reference documentation should unequivocally define the contract of each API. Also I think the documentation should make it very clear what Nowide does and doesn't do on different platforms. Especially that it doesn't do anything Unicode-related on POSIX platforms and that using it does NOT mean the application will only have to deal with UTF-8 strings on POSIX platforms. Also parts of the documentation that suggest or even _state_ that systems like Linux internally use UTF-8 should be fixed. > - What is your evaluation of the potential usefulness of the library? I'd say it's useful. > - Did you try to use the library? With what compiler? Did you have any > problems? No. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Quick reading of the documentation + some very quick glances at parts of the implementation. > - Are you knowledgeable about the problem domain? More or less. I have never used or written a "nowide" layer myself, but I have spent plenty of time "widening" Windows-only applications. > And most importantly: > - Do you think the library should be accepted as a Boost library? Be sure to > say this explicitly so that your other comments don't obscure your overall > opinion. I certainly wouldn't vote against it. I didn't spend enough time to understand every aspect of it though, so I don't feel qualified to vote for it either. I would however suggest to require a major update of the documentation before accepting it. Regards, Paul Groke

4 12

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 23 Jun '17

23 Jun '17

Am 20.06.2017 5:08 nachm. schrieb "Niall Douglas via Boost" < boost(a)lists.boost.org>: >> Niall says that using the global BUILD_SHARED_LIBS is a cmake2ism, and >> that explicit targets are preferred nowadays. > > Niall, can you point me to a reference stating this? Preferably some cmake > documentation telling me what the right(tm) thing to do is. Any cmake construct which requires you to write an if() in a non-root-level CMakeLists is a cmake2-ism. There are a very few places in cmake3 remaining where no good alternative to global variables exist. BUILD_SHARED_LIBS is definitely not one of those. I'll ask again: do you have any reference to those statements? The official cmake docs seem to disagree about this specific case. I would even call it non sensical alltogether. Why should the root cmake be responsible for configuring a specific sub module. This is asking for cluttering everything into one single entity in a (almost) totally unrelated place. Why not keep it local to where it should be used. One concrete example: I have networking layer which supports different transports, say tcp, libfabric, MPI and infiniband verbs. The user of my library doesn't really care about which one is used, so ideally, I would give him a compiled version of my library with the internal settings I believe are best for him. In that case, my network layer module would be configured with one of those options. Naturally, I would think, those options are defined within this very sub project. The root project really doesn't care, nor do I want that this implementation detail leaks into the users CMakeLists.txt. Would you consider that bad practice to begin with? How would you solve this? There are tons of other use cases very similar to that. Having everything clobbering up in the root Cmakelists.txt doesn't sound appealing to me. Shared libraries usually have different settings to static libs and again to header only libs. They have different relationships to their dependencies, different usage requirements for consumers. You can use generator expressions to encode those differences, but then you've hard coded them so external cmake no longer can easily override them. You have just made your non-root CMakeLists hard to reuse by cmake you didn't write nor design. Generator expressions are also hard to write and debug, are overwhelmingly confusing to read, and randomly don't work in some places depending on which build system generator you are using. So best avoid all of that complexity - place no complexity at all outside the rootlevel CMakeLists. Declaration only. Place all custom logic solely in rootlevel CMakeLists only. > Any definite source on what a cmake2ism is or is not would be highly > appreciated. > > > As a general observation, I see a lot of statements along the lines of "I > state that XYZ is preferable over UVW", it would be nice to have to have > background information (pros and cons anyone? what do the cmake > authors/docs have to say about this?) on those statements so that everyone > can form their own opinion instead of having to choose whom to trust about > what's "standard" cmake. I believe Stephen Kelly is negotiating a book deal on this. It'll be some time before that book lands though. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

13 42

[build] Use address-model in library filenames
by Vinnie Falco 23 Jun '17

23 Jun '17

Please add the address-model (32 or 64) into the encoded name which describes a library, so that 32-bit and 64-bit libraries may reside in the same dir. I'd like to avoid a lengthy debate, and if no one wants to do it just provide me with working code for accomplishing it and I'll submit a pull request. -- Follow me on Github: https://github.com/vinniefalco

5 4

Outcome/expected/etc/etc/etc
by Gottlob Frege 22 Jun '17

22 Jun '17

I've now read ALL the emails. Here's some thoughts, in no particular order. - I wonder, Niall, if your uses of the empty state could/should be compared to how people sometimes use -1 or 0, etc - ie "special values as errors". I typically don't like that pattern (yet I've done it anyhow - performance/laziness/etc - but typically only in localized cases, not in "APIs"). So I'm wary about this empty state thing. If we do have an empty state, I like it as a separate type - code needs to deal with it separately. I like the idea of taking a possibly-empty type, checking for empty, and creating a never-empty type, and passing that along so future code need not worry. - I think the narrow and wide contracts should be in the same type, not separate types. This is C++. I suggest "access" if you want long names. ie T & val = oc.access_value(); // possible UB (I almost also suggested "deref" but "deref_value" is wrong - you are deref'ing the outcome, not the value) - I agree with Vicente's concern that functions that behave differently need to be named differently. I haven't looked at the new (or old) API carefully enough, but as a (possibly hypothetical) example: wide_type::value() // returns value, or throw if no value narrow_type::value() // returns value, or UB if no value These functions are not the same, and should not be named the same. Since you thus need different names anyhow (ie value and access_value), why not put them both on the same API? I'm not yet sure if you end up with similar examples with possibly_empty_type::something() and never_empty_type::something(). - I see value in the idea that the narrow contract takes more typing, but I actually *like* using * and -> for the narrow contract because I have 30+ years of training in looking at * and -> and recognizing it as "this may be unsafe, examine the code to see how it is guaranteed". Boost.Optional specifically chose * for that very reason. (on the other hand, I have 0 training on spotting access_value(), but on the third hand, it is easy to grep for) - exception() returns error, error() doesn't return exception, etc: would it be better/easier/clearer if we introduced another name, such as "failure" or whatever? ie exception() only returns the stored exception, error() only returns the stored error(), and then has_failure() would return true in either case, failure_exception() returns exception, generates an exception from error if necessary, etc? - I dislike "exceptions are for exceptional circumstances". Yes it is a common thing, but it is usually wrong. Using Outcome to enable the pattern of "handle errors, but totally cancel the operation on exceptions" might actually turn out to be a useful pattern, but I think this is actually slightly different from the "exceptions are for exceptional cases" camp, as they typically use that chant to choose whether their API will use exceptions or errors, not both in a single API. So I agree with Emil - for most APIs, error-codes vs exceptions" is basically trying to handle the same thing - failure (or "disappointment"). Using both error-codes and exceptions in a single API is somewhat new. And interesting. (There is lots of code that almost-unknowingly uses error-codes and exceptions in the same API, but that is because they don't realize push_back throws or they pretend it doesn't, etc - it isn't really an API design choice) - this ring buffer thing sounds interesting. I haven't looked at it at all, so maybe this makes no sense: should it use thread-local? - I think std::expected should always throw something deriving from std::exception. So if E derives from std::exception, we can throw it. If E is exception_ptr we can (re)throw it. If E is error_code/system_error/etc we can figure out what to throw. If E is user-type, then we wrap it in bad_expected or whatever. (And/or allow user E-to-exception customization somehow). This sounds complicated, but it is easily summarized/taught as "the standard always throws std::exceptions" - I HATE the dual interface of std::filesystem. Worse, there is a chance it is setting a precedent for future std APIs (dual APIs have been proposed elsewhere). Let's please kill it before a dual API strikes again. However, the other problem with trying to "single-fy" the std::filesystem (or any other) API is that users who want error codes sometimes don't want the cost of the extra data (paths, etc). The only way to handle that may be with customizable callback functions that capture the error-info however you like, or something similar to callbacks. - I really look forward to Peter's never-empty variant - and have been hoping for one ever since std::variant was finalized. Not because I dislike std::variant, but just because I think the option should be there for those who need/want it. Regardless, std::variant, in my world, is never empty, since it is only empty when a move operator throws, which should be never and/or when I can't allocate 64 bytes, in which case I'm screwed anyhow. Some days I'm like "man just accept empty, it would be a simple API", but then I think "it is stupid for variant<int, double> to be empty". Other days I think "just double buffer when necessary" (I assume that's your direction Peter?), but then I think "I don't want double-buffering variant<list, vector> to go on/off based on whether I use MS std vs libc++ etc" and also "I don't want double buffering for cases that only happen in theory, not in practice". I like the trade-offs of std::variant. I do agree that Boost should have a variant2 with different choices than std::variant - I think that actually helps the standard - we can choose a direction and instead of telling people "tough luck" when they disagree, we can say "use boost variant2 when you want those properties". - Andrzej: > Actually, now I am thinking not about Boost.Outcome but specifying these > preconditions in the Standard. If you want to std::terminate upon some > condition rather than let the program do random things, you could say. > > *Requires:* `!r` with rescue action `std::terminate()`. This sounds a bit like the contracts proposal - where you get to define what happens when contracts are broken. I'm cautiously hopeful that contracts could help with LEWG's constant struggles with wide vs narrow. - I agree with those who were saying (or thinking) that Boost was - and should again be - the place where APIs go before going into the standard. APIs (mostly) shouldn't bypass boost and go to the standard directly. Or at least an API needs a similar user-base (both in scale and diversity - ie an internal google API has scale, but not necessarily diversity). Since I know a number of LEWG members agree with me on this, don't be surprised to see some push-back from the committee for proposals without that kind of backing, and also don't be surprised if Boost gets flooded with "the committee told me to come here first". Of course I don't speak for LEWG, so maybe none of that happens, we haven't had that discussion yet. I actually probably had more to say - I should have made notes as I was reading all... those... emails. Tony

10 75

[review] Review of Nowide (Unicode) starts today
by Frédéric Bron 22 Jun '17

22 Jun '17

Hi Everyone, The formal review of Artyom Beilis' Nowide library starts today and will last until Wed. 21st of June. Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

11 70

[cmake] Minimum viable cmakeification for Boost
by Niall Douglas 22 Jun '17

22 Jun '17

I've finished the mockup which can be studied at: https://github.com/ned14/boost-bmv-cmake Just Boost.System was cmakeified. Extensive comments are throughout to explain every single line of cmake and why it's there. A small sample program is in the root of the repo to show how this cmake would be used by end user programs. Readme.md follows for those who don't like clicking on links: --- cut --- This is a mock up of a **bare minimum viable** cmakeification of the Boost C++ libraries for the community to study and evaluate. It only cmakeifies Boost.System alone, its upstream dependencies are stubbed/faked. A demo program which shows how one would link against Boost.System is in this directory (`example_client_program`) and it demos linking against boost::system as a header only library, as a static library and as a shared library. # Specific design goals of this mock up: - Modern, **highly reusable by unknown third party cmake** cmake3 only throughout. - Minimum possible cmake complexity, no cmake innovating, even at the cost of extra boilerplate. - No custom macros, functions, nor custom build logic. Only vanilla cmake3. Keep the learning curve for the build system as gentle as is possible. - **Strict** separation of non-fixed configuration and build. Child CMakeLists must only EVER define build and *fixed* configuration like "I need C++ 11 minimum". *Variable* configuration like naming, directory layout for outputs, optimisation flags etc is ALWAYS defined in the **rootmost** CMakeLists. NEVER in child CMakeLists. - All custom build logic should always be placed in rootlevel cmake scripts (command line programs written in cmake, runnable using `cmake -V`, these can take args etc) or rootlevel CMakeLists, or combinations thereof. # Stuff in there we might yet remove: - This cmake mockup explicitly documents dependencies between Boost libraries in cmake, and so when I link against say Boost.System, cmake will also link in the things Boost.System depends against. Moreover this is minimal, so ONLY the stuff minimally necessary to fulfil the need for Boost.System is built. - We allow those Boost libraries support it to present header only, static and dynamic linkage editions of themselves. This does complicate the CMakeLists however. # What we don't do: - Test the boundaries of cmake or push any limits of what's possible. - Bespoke libraries of common functions dragged in wherever. - Complex custom build logic which needs to be documented and learned off by library developers. - Do anything which gets in the way of CMakeLists reuse by any arbitrary third party cmake written by any Boost user. --- cut --- The code should be fairly self explanatory. Yes there are no tests support. We are limiting the scope of discussion to build only for now. Technical questions are welcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 50

[review] Beast review coming up!
by Michael Caisse 22 Jun '17

22 Jun '17

The Boost formal review of Vinnie Falco’s Beast library will take place July 1 - 10, 2017. Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocol vocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. This library will be familiar to programmers that have used Boost.Asio or the Networking TS. Users who wish to use asynchronous interfaces should already know how to create concurrent network programs using callbacks or coroutines. Beast is designed for: * Symmetry: Algorithms are role-agnostic; build clients, servers, or both. * Ease of Use: Boost.Asio users will immediately understand Beast. * Flexibility: Users make the important decisions such as buffer or thread management. * Performance: Build applications handling thousands of connections or more. * Basis for Further Abstraction. Components are well-suited for building upon. Beast can be found here: * Documentation : <http://vinniefalco.github.io/beast/> * Source code : <https://github.com/vinniefalco/Beast> * The FAQ answers real questions that come up : <http://vinniefalco.github.io/beast/beast/design_choices/faq.html> A lightning talk from CppCon 2016 introducing Beast can be found here: <https://www.youtube.com/watch?v=uJZgRcvPFwI> If you find an obvious bug or problem with the library, please open a GitHub Issue <https://github.com/vinniefalco/Beast/issues>. Vinnie has a track record of resolving issues quickly. Please feel free to take an early look at the library and ask questions. Maybe even click that github Star button! The actual review will be against a non-mutating branch starting July 1st. -- Michael Caisse Ciere Consulting ciere.com

2 1

[build] Use full compiler-version in library filenames
by Deniz Bahadir 22 Jun '17

22 Jun '17

Hi list, While reading Vinnie's mail (regarding the Boost library filenames which should additionally contain the address-model) I remembered another problem existing with library filenames. That is, that Boost libraries built with newer GCC versions (since GCC 5) never add the compiler-version into the library filenames. Building with GCC 5 and newer only adds "gcc" into the filename to determine the toolset, while building with earlier versions of GCC (e.g. GCC 4.9 or GCC 4.8) additionally adds the compiler's version (e.g. "gcc49" or "gcc48"). I assume this might be due to the fact that the version-scheme of GCC changed since GCC 5 and somehow the logic in Boost.Build no longer works because of this. But in order to install boost-libraries built by different GCC versions side-by-side in the same directory the version-number is really required in the filename. Maybe someone can fix this again? A bug-report on Github which addresses this issue already exists: https://github.com/boostorg/build/issues/191 Thanks in advance, Deniz -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Winterfeldtstr. 21 10781 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Advisory Board (Chairman): Stephan Schröder Board of Management: Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

2 1

[review] Review of Nowide has finished
by Frédéric Bron 22 Jun '17

22 Jun '17

Thanks for you interest and the discussion. Please be patient, it will take a few days for me to compile all the discussions and give the result of the review. Kind regards, Frédéric

1 0

1.65 closes for new libraries and breaking changes this Friday
by Marshall Clow 22 Jun '17

22 Jun '17

[ The calendar says today, but I forgot to send this out, so we're pushing the deadline back two days. ] Upcoming release dates: 28-Jun: Boost 1.65.0 closed for major changes 5-Jul: Boost 1.65.0 closed for all changes, except by permission of a release manager. 8-Jul: Boost 1.65.0 closed for all changes 12-Jul: Boost 1.65.0 beta; master branch re-opened 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 -- Marshall

1 0

Re: [boost] [review] Review of Nowide (Unicode)
by Yakov Galka 21 Jun '17

21 Jun '17

Dear all, Here is my review of the library. - What is your evaluation of the design? > I welcome the UTF-8 approach on Window. However, the fact that Nowide does not handle invalid UTF-16 transparently is an issue that has to be addressed. - What is your evaluation of the implementation? > Going through the code I can't spot any implementation issues. > - What is your evaluation of the documentation? > It's clear. No issues found. > - What is your evaluation of the potential usefulness of the library? > I already use this approach through a different implementation. Even though I wouldn't bring Boost just for that single library, for projects that already use Boost it might be a valuable addition. I do think that Nowide offers a superior solution to encoding issues compared to Boost.Filesystem. > - Did you try to use the library? With what compiler? Did you have any > problems? > I did try it years ago when it was first submitted to Boost. I didn't try the recent version, so NO. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > 30 minutes reading the code + mailing list discussions. > - Are you knowledgeable about the problem domain? > I rate myself as an expert. I'm a co-author of utf8everywhere.org. DISCLAIMER: I met Artyom a couple times IRL. > - Do you think the library should be accepted as a Boost library? Be > sure to say this explicitly so that your other comments don't obscure > your overall opinion. > Conditional acceptance, subject to transparent invalid UTF-16 resolution. -- Yakov Galka http://stannum.co.il/

4 3

[review] Last day to send your review of Nowide (Unicode)
by Frédéric Bron 21 Jun '17

21 Jun '17

Dear all, This is the last day to submit your review of Artyom Beilis' Nowide library. So far, 12 people participated to the review (not counting the author and the review manager): - Andrzej Krzemienski - Chris Glover - Degski - Edward Diener - Gavin Lambert - Niall Douglas - Norbert Wenzel - Paul Groke - Peter Dimov - Vadim Zeitlin - Yakov Galka - Zach Laine 8 reviews where received including * 6 reviews said nowide should be accepted (with conditions): - Degski, - Peter Dimov - Andrzej Krzemienski - Chris Glover - Norbert Wenzel - Yakov Galka * 1 review did not choose between accept/do not accept: - Paul Groke * 1 review said nowide should not be accepted as is: - Zach Laine Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

1 0

[sort] Timsort review result
by Steven Ross 21 Jun '17

21 Jun '17

After reviewing the responses, I have rejected Timsort. Here are the reasons: 1. No author/maintainer responses to the questions on boost (except for forwarding some documentation links). We need a maintainer for all our source, and I'm not volunteering to maintain new functions as complex as Timsort. 2. There was no response on the Timsort bug reported during the review, nor any tests for it. 3. We need better tests. 4. Francisco is including a more efficient stable sort as part of his additions to the library, including handling special cases like Timsort handles better than stable_sort does. Francisco will maintain his code. I'd like to note that many people THINK they are experts on sorting because they covered it in class or may have read about it in a textbook, but most do not understand hybrid sorts well. As a specific example, I saw O(N*log(N)) mentioned as the worst-case speed limit of general-case sorts, when in fact Spreadsort beats that as described in its docs: http://www.boost.org/doc/libs/1_61_0/libs/sort/doc/html/index.html#sort.ove… Many people also don't carefully analyze for worst-case performance, which can be tricky. With regards to future sorting library reviews, I'll get at least a one-page doc describing the algorithm for the review in advance, but the boost documentation formatting is an unreasonable request for a simple sorting function, and I don't see the value it adds for these simple reviews. It is useful for a full library, but we'll be integrating the documentation into our full library after a new function is accepted. It isn't accurate to call it a mini-review (as described here: http://www.boost.org/community/reviews.html#Fast-Track) because it's reviewing completely new source we're talking about adding to the library. That said, do you still want me to a call the upcoming one for pdqsort a "mini-review"?

3 3

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 20 Jun '17

20 Jun '17

Am 20.06.2017 2:17 nachm. schrieb "Niall Douglas via Boost" < boost(a)lists.boost.org>: On 20/06/2017 07:27, P F wrote: > >> On Jun 19, 2017, at 6:42 PM, Niall Douglas via Boost >> <boost(a)lists.boost.org> wrote: >> >> I've finished the mockup which can be studied at: >> >> https://github.com/ned14/boost-bmv-cmake >> >> Just Boost.System was cmakeified. Extensive comments are throughout >> to explain every single line of cmake and why it's there. A small >> sample program is in the root of the repo to show how this cmake >> would be used by end user programs. > > Here some feedback, I have: > > - Having things like `::hl` or `::sl` is quite strange. In cmake, I > set `BUILD_SHARED_LIBS=On` when I want a shared library or I set it > to `BUILD_SHARED_LIBS=Off` when I want a static library. There should > only be one target `boost::config` or `boost::system` that I use. BUILD_SHARED_LIBS is a cmake2-ism and should not be present in modern cmake. Moreover, cmake now supports header only libraries, and BUILD_SHARED_LIBS causes problems with eventual C++ Modules support. The ::hl suffix means "link against the header only library edition", the ::sl suffix means "link against the static library edition" and the ::dl suffix means "link against the dynamic library edition". Err, I tend to highly disagree here. As a library author, I can not know if my users need a static or shared library. For a header only library, this hardly matters. Having those different conventions greatly increases the complexity for consuming your library (which do I need again in which circumstances?) so we need to depend on variables to link against the right target (so much for cmake2isms). Some bikeshedding over those names occurred off list. They don't hugely matter, they could be boost::system::header, boost::system::static and boost::system::shared if you wanted. Some bikeshedding also occurred over what boost::system with no suffix should mean. I recommend "whatever library edition the maintainer recommends as the best one" which is NOT necessarily the header only edition. For example, in the future with C++ Modules support the additional suffixs ::hlm, ::slm and ::dlm will be needed. Or longer named, boost::system::header_module, boost::system::static_module and boost::system::shared_module. So if C++ Modules were available, the maintainer might recommend the ::dlm variety, but recommend the ::hl variety if they weren't available. I think that will hugely vary per library as C++ Modules won't necessarily be always a win. Also, end users may wish to assemble all of Boost into a single C++ Module. We don't want to get in the way. > - Each project do things like > `include("${CMAKE_CURRENT_SOURCE_DIR}/../../cmake/BoostVersion.cmake”)` > which is broken when built on its own. That was intentional. Some bikeshedding occurred over that too with respect to which Boost library guaranteed to be a dependency for all other libraries ought to host the version setting script. Boost.Config is most likely. So the above is a placeholder. > - Doing `if(NOT TARGET boost::assert::hl)` is wrong. A target does > not have to exists to be able to link against it. Plus, it should > call `find_package(boost_assert)` to bring in the target for when its > not built in the superproject. That part is there solely to enable modular build. If you don't want to bother with modular build as this is a bare minimum viable cmakeification, you can eliminate it. > - There is no installation of the targets Not necessary right now, so out of scope. > - Doing `target_include_directories(boost_core-hl INTERFACE > "include”)` is wrong as this will only add the include directories > for the build. The include directories should be added for the build > and for the installation. As I've repeatedly explained now, installation logic is best implemented by a rootmost CMakeLists. Not in the per-library CMakeLists. We do tell cmake what targets are used by installation via install(TARGETS ...). That's the bare minimum needed for other cmake to implement the remaining installation logic. (On wider picture stuff, install paths need to be absolute I've found, whereas build paths can usually be relative. Relative paths are much nicer during build. In a rootmost CMakeLists which implements some installation logic, you'd iterate the targets for the Boost libraries and configure each programmatically for the appropriate install for that library and that type of library. All the metadata you need to make decisions is available) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 5

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 20 Jun '17

20 Jun '17

Am 20.06.2017 4:21 nachm. schrieb "Peter Dimov via Boost" < boost(a)lists.boost.org>: Thomas Heller wrote: > As a general observation, I see a lot of statements along the lines of "I > state that XYZ is preferable over UVW", it would be nice to have to have > background information (pros and cons anyone? what do the cmake > authors/docs have to say about this?) on those statements so that everyone > can form their own opinion instead of having to choose whom to trust about > what's "standard" cmake. > That's the problem with CMake, there's no way for someone like me who does not follow it to get a definitive answer to what idiomatic CMake 3.5+ is. There are several articles about it, they all say more or less the same thing - use target_*. I get that. But that's not enough. I see a general (and very predictable) trend of moving from imperative to declarative. Programmers like imperative, but a proper build system really prefers declarative, so CMake is trying to evolve towards declarative. Take for example find_package. It's a command, find me this package, now. But it's much better if a library does not issue "find me this package" commands, but rather declares which packages it needs. So we get "best practice" hacks like redefining find_package. I'm sorry, this doesn't feel right. I hear what you're saying. We'll end up innovating cmake, which for me isn't a bad thing. I'm favoring CMake due to its great support for generating for all kinds of different environments (including proper visual studio solutions). To be fair, I haven't invested as much time in boost.build as I did for cmake. For all platforms I work on, both work equally nice with different quircks on different ends. I'm not using an ide though. For the sake of ide support, I'd lean towards cmake. Regarding the discussion of what's right and wrong when writing your CMakeLists.txt files, it's almost bike shedding. If you want to depend on a library, you'll make it work, no matter what, that's what we do. Nevertheless, in terms of cmakeisms, I really like what Paul put together and what Daniel Pfeifer said in his talk makes a lot of sense in a cmake world. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

1 0

proposal - modularize Boost build system
by Stefan Seefeld 20 Jun '17

20 Jun '17

One of Boost's bottlenecks is its monolithic build infrastructure. It would be beneficial for many different use cases (testing, packaging, etc.) to decouple the building of Boost libraries (well, those that require building, see the listing in http://www.boost.org/doc/libs/1_64_0/more/getting_started/unix-variants.htm…) such that they may optionally be built stand-alone. At present, building a Boost library requires the entire (super-)repository to be checked out, and the build logic itself involves traversing the entire source tree, looking for a "Jamroot". What would be beneficial to many would be a workflow like this: 1) Have a development environment with (some version of) Boost pre-installed (or at least the parts that the library being built depends on). 2) Check out a single Boost repository (e.g., https://github.com/boostorg/python) 3) Invoke a command to build it (if there is anything to build) 4) Invoke a command to test it 5) Invoke a command to install it 6) Invoke a command to package it (optional) While it's of course already possible to do all the above by adding support for another build infrastructure (point in case: Boost.Python right now uses SCons for this very reason), this means duplication of effort, as Boost as a whole is still built, tested (and even packaged for binary packages) using Boost.Build, meaning I need to maintain two sets of build infrastructure. This proposal thus has two parts: 1) Make the nested build logic independent of the outer bits, so individual libraries can be built stand-alone (for example, using b2 by adding a `--with-boost` set of options to point to the location of the prerequisite parts of Boost). 2) Define a clear interface the outer build logic will use to invoke the nested build commands. Note that for my own case above (Boost.Python), providing 2) would be enough, i.e. by having a way for me to "plug in" my SCons commands to build and test Boost.Python could obsolete the existing Boost.Build logic as defined in Boost.Python (as well as the prerequisite parts in Boost.Build's "python" module). However, as my proposal is *not* actually advocating to move away from Boost.Build, but rather to modularize it, I think 1) is essential to let everyone else (who may not be inclined to use anything other than Boost.Build) to also take advantage of modularization. While I'd rather avoid delving into the technical details of how this could possibly be implemented (if you really must, *please* do so in a new thread !), let me outline a few use-cases that would be made possible by the above: * individual projects would be free to switch to their preferred infrastructure, including CMake, SCons, etc., if they so wish * individual projects could be much more easily developed and contributed to * individual projects could be much more easily tested, notably in CI environments * individual projects could be much more easily packaged All of the above advantages are *huge*, and reflect real-world needs, and the technical issues to solve these are all minor. The question really is whether there is enough will to move into that direction. I'd be very happy to participate in the work needed to implement this. But first we need to agree that this is where we want to go. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

14 46

Review of Nowide
by Chris Glover 20 Jun '17

20 Jun '17

Hi, The following is my review of the proposed Boost.Nowide library. This is my first official review of a boost library, so please forgive me if I've missed anything. - What is your evaluation of the design? At first I was surprised by lack of a platform agnostic encoding. However, through reading the docs and the discussion in the list, I believe this to be the correct choice. If a user has a need for a common encoding, I believe that would be best served by a different library that would ultimately have different issues and performance characteristics. One thing I'm not sure about is if the overlap between the fstream implementations in filesystem and nowide is necessary. It seems to me that if I set filesystem to be nowide aware (via boost::nowide::nowide_filesystem) then there's little reason for the nowide versions of the stream objects to exist, other than possibly eliminating one string copy on non-windows platforms and avoiding the filesystem dependency (and maybe those are good enough reasons). - What is your evaluation of the implementation? I only gave the implementation a glance. It looks good; clean, organized; with a full test suite and nothing weird stands out. It seems to be of the typical quality I expect from a boost library. - What is your evaluation of the documentation? The documentation is clear and complete, but I think it needs to explain at the top that the library does not present a uniform encoding for strings. This is discussed in the documentation near the end, under "Q & A", but I think it should be near the top. A suggestion is to add a section called "What Boost.Nowide is *not*" directly under the section titled "What is Boost.Nowide", otherwise I expect some users to be surprised. - What is your evaluation of the potential usefulness of the library? It is very useful. I am already using it. - Did you try to use the library? With what compiler? Did you have any problems? I converted one application that was using boost::filesystem::path to transport filenames around to use nowide instead. I had no issues, everything just worked. Some code was also simplified as a result -- not dramatically, but enough that it felt better. I tested the application on windows only using Visual Studio 2017. I also ran the tests under MSYS2 on Windows using gcc-6.3, on Windows using MSVC 2017 and on Ubuntu using gcc-7. Under MSYS, one test failed (Fail: Error boost::nowide::cin.putback(c) in test_iostream.cpp:17 main), but I haven't had a chance to look into why yet. All of the tests passed on the other platforms. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I followed the discussion, read the docs, integrated the library, used the API and tested the resulting program. All in, I think that took me about 4 hours. This seems quick, but to me that is a testament to a solid design and clear documentation because the conversion process was very simple. - Are you knowledgeable about the problem domain? I am aware of the problem and have worked around it in the past by using filesystem::path as a string. However, most of the environments I work in professionally are controlled in a way that allows us to avoid this problem most of the time, so I have not had extensive experience with it. - Do you think the library should be accepted as a Boost library? Yes. I am already using it and expect I will be using it a lot more going forward. -- chris

2 2

[nowide] review
by Andrzej Krzemienski 20 Jun '17

20 Jun '17

Hi All. This is a review of Boost.Nowide library. I am not really familiar with the problem. I used to do trivial tasks with files on Windows, but they were always ASCII, so the problems solved by Boost.Nowide never affected me. I am also not fa,iliar with the problems of converting from Windows encoding (*WTF* seems like the right choice of name) to UTF-8. I have read the documentation, and got some additional information from the author. I have downloaded the library and have run a toy program that plays with names that cannot be encoded in a single code-page. I am testing on Windows 7, MinGW, GCC 6.3, with -std=c++03. Compilation and linking works fine. Tests work fine too. Then, I tried the same example with normal `std::ifstream` and it did not work on Unicode file names and strings, which conforms that Boost.Nowide solves an existing problem. DESIGN: clear, logical, intuitive. IMPLEMENTATION: I did not look at. DOCUMENTATION: clear. POTENTIAL USEFULNESS: as specified in the docs, if you want to do things with multilingual strings in a platform independent way, you need a library like this. I vote to *ACCEPT* the library. I may not be qualified enough (the manager will weigh my vote), but the desctiption of the library, as well as the replies from Artyom convince me that the library addresses the problem in the right way and is reliable. Artyom, thanks for sharing this library, and submitting it for review. One minor thing. In th be docs (http://cppcms.com/files/nowide/html/) we read: boost::nowide::widen <http://cppcms.com/files/nowide/html/namespaceboost_1_1nowide.html#a6baacc1b…> returns std::string. I thing is thsould be std::wstring? Regards, &rzej;

2 5

Atomic Shared Ptr
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi, Does Boost have anything like concurrency TS' atomic_shared_ptr? Gr, -- Olaf

3 7

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

Sanitizer bug or undefined behavior in format?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi, I think it's about rdbuf() which doesn't appear to be virtual. Is this a bug in the sanitizer or is this call not allowed? alt_sstream.hpp: basic_oaltstringstream(stringbuf_t * buf) : pbase_type(buf, No_Op() ), stream_t(rdbuf()) { } $ g++ a.cpp -fsanitize=undefined && ./a.out /usr/include/boost/format/alt_sstream.hpp:146:60: runtime error: member call on address 0x7fffdb4f36a0 which does not point to an object of type 'basic_oaltstringstream' 0x7fffdb4f36a0: note: object has invalid vptr 00 00 00 00 00 00 00 00 00 00 00 00 18 3a 4f db ff 7f 00 00 b0 4c 37 fa 66 55 00 00 28 5b 0d 80 ^~~~~~~~~~~~~~~~~~~~~~~ invalid vptr a.cpp: #include <iostream> int main() { std::cout << boost::format("%d") % 1 << std::endl; // std::cout << boost::format("%04d-%02d-%02d") % (date->tm_year + 1900) % (date->tm_mon + 1) % date->tm_mday << std::endl; return 0; } -- Olaf

2 2

Re: [boost] proposal - introduce API & ABI compatibility guidelines
by Brian Wood 19 Jun '17

19 Jun '17

Artyom Beilis writes: > The problem is that it isn't going to change in near future because > it is almost impossible to reach a consensus of some strategic > direction because any major change will find enough developers > who will not want one. > > So today I use boost only in applications and never in libraries. I'm only comfortable using Boost in private/closed source applications. I think on line code generation will help with some of the packaging problems discussed in this thread. Brian Ebenezer Enterprises - Enjoying programming again. http://webEbenezer.net

1 0

proposal - introduce API & ABI compatibility guidelines
by Stefan Seefeld 18 Jun '17

18 Jun '17

Following up on this point made by Peter Dimov in another discussion: > This is part of the price you pay for being accepted as part of Boost > - the duty to act as an integration test for your Boost dependencies. > This is beneficial for you in the long term, because you can detect > breaking changes in your dependencies before they get shipped. If you > only test against 1.56, and 1.64 breaks your library, you won't hear > about it before 1.72. This does you no good, and it does your users no > good. You WANT to know if changes in 1.65's SmartPtr would break you > BEFORE 1.65 gets released. The real problem that you are touching here is Boost's lack of any sort of ABI or even API stability. So Boost 1.X and Boost 1.(X+1) are two distinct packages, as there is no metric that enables even to measure the amount of incompatibility between the two. Any normal library that's used in-production would have strong requirements for backward compatibility, to enable users to reason about the risk of upgrading etc. Thus, to follow up (and not pollute the original discussion about modularization), I'll propose the following: I'd like to see guidelines to be established for: * what API and ABI changes may be applied in a given release * have a clear definition of version numbers (major, minor, bug fix) with associated semantics * impose testing requirements to enforce the above. Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 1

[nowide] request for clarification
by Andrzej Krzemienski 17 Jun '17

17 Jun '17

Hi Everyone, I admit I am not quite familiar with the problem, but I understand that as one of the features, nowide offers a replacement for std::fstream that can be constructed with its string types. At the same time we have boost::filesystem that offers its own replacement for std::fstream that can be constructed with filesystem::path. Now, if I want to use `filesystem::path`s in my program (to be able to tell just any string from a filesystem path), can I still use the benefits of `nowide` library? Also, in the docs for nowide::ifstream, we read, "Same as std::basic_ifstream<char> but accepts UTF-8 strings under Windows." What about other systems? What does it accept on Linux? ascii? In documentation for `nowide::args`, we read, "args is a class that fixes standard main() function arguments and changes them to UTF-8 under Microsoft Windows." Does it write to the input strings in-place? is it even legal in C++? It "fixes", which implies that otherwise the args are "broken". How are args in function main() broken? (other than not being UTF-8)? Regards, &rzej;

5 9

[review] More reviews of Nowide are welcome
by Frédéric Bron 16 Jun '17

16 Jun '17

Hi all, More official reviews are welcome for the boost nowide library. It's a small and very useful library, please consider taking some time to give us your feedback. Please answer the questions at the bottom of this message. Cheers, Frédéric (review manager) ---------- Forwarded message ---------- Date: 2017-06-12 6:20 GMT+02:00 Subject: [boost][review] Review of Nowide (Unicode) starts today Hi Everyone, The formal review of Artyom Beilis' Nowide library starts today and will last until Wed. 21st of June. Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

1 0

Re: [boost] [review] Review of Nowide (Unicode) starts today
by Artyom Beilis 16 Jun '17

16 Jun '17

How would you therefore do this simple task: 1. get a directory from nowide::getenv -> base_dir (UTF-8 on Windows, unknown narrow on Posix) 2. create a file in base_dir which name is file_name encoded in UTF-8 (because it is created by the application). If I understand well, I should NOT do this: auto f = nowide::ofstream((boost::filesystem::path(base_dir) / file_name).string()); because this is guaranteed to work only on Windows where I have the guarantee that base_dir is UTF-8, right? Actually it is what exactly you should do. Once you turn on **nowide integration** with boost filesystem path::string does not perform any conversions on POSIX platforms. And you can safely concatenate two different strings and valid file will be created. Even if dir is in ISO 8859-1 and file in UTF-8. The file will be valid even if not representable in any encoding. Under windows you'll get the correct conversions from narrow to wide using the utf8/16 facet installed by boost.nowide/Filesystem integration as on Windows boost filesystem uses wide strings Artyom

4 4

[interprocess] how to use lock_file with Unicode file name?
by Frédéric Bron 16 Jun '17

16 Jun '17

Hi, I have been using lock_file with ASCII file names without any trouble. Now I would like to be able to use non ASCII file names. How does it work? Currently, lock_file uses as input const char *. What about the encoding? Cheers, Frédéric http://www.boost.org/doc/libs/1_64_0/doc/html/boost/interprocess/file_lock.… http://www.boost.org/doc/libs/1_64_0/doc/html/interprocess/synchronization_…

1 0

Re: [boost] [review] Review of Nowide (Unicode) starts today
by Frédéric Bron 15 Jun '17

15 Jun '17

> at Linux nowide fstream is > an alias to std::fstream If course! Frédéric

1 0

[config][android] GCC-5 and 6 failures.
by John Maddock 15 Jun '17

15 Jun '17

There are some runtime (segfault) failures running config_test on andoid, see for example: http://www.boost.org/development/tests/develop/developer/CrystaX-apilevel-2… Can anyone with access to this platform (or preferably the test runner) see if defining BOOST_NO_CXX11_THREAD_LOCAL fixes the issue? That would be my hunch for the problem anyway. Many thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 2

[random] Request for Additional Generators
by degski 15 Jun '17

15 Jun '17

I would like to request the addition of 2 generators to Boost.Random. xoroshiro128+ <http://xoroshiro.di.unimi.it/xoroshiro128plus.c> Web page: http://xoroshiro.di.unimi.it/ A very fast PRNG, (quite a lot) faster than the fastest current boost generator, with a period of 2 ^ 128, which could/would be good for f.e. game programming (except for shuffling, see below). It also has a state of only 16 bytes on x64. The author states that the distribution is of higher quality than f.e. MT19937-64 <http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-6…>. It's probably best to just read the web-page, as it goes into quite some detail and is in itself the summary of the research conducted in this area. Other than the normal boost complications, it's very easy to implement and I use my simplistic implementation to great satisfaction with the std and boost distributions. In this <https://www.codeproject.com/Tips/1083372/Random-Number-Generator-Recommenda…> article on CodeProject the issue of shuffling is raised. It's appears that shuffling of large arrays of data requires a generator with extremely long periods in order to be able to generate all the possible permutations. To this extent I would like to see in boost a generator like George Marsaglia's SuperKiss <https://groups.google.com/forum/#!topic/comp.lang.fortran/QiTrbq0XeyM> or/and a templated SFMT generator like this <https://sourceforge.net/p/int64/svn/HEAD/tree/snips/sfmt.hpp> one. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 3

[review] Review of PolyCollection starts today (May 3rd)
by Ion Gaztañaga 15 Jun '17

15 Jun '17

Hi everyone, The formal review of Joaquín M. López Muñoz's PolyCollection library starts today. I'd like to encourage your participation as the proposed library is small and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and propose improvements. PolyCollection implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. The library can be found here: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html Please post your comments and review to the boost mailing list (preferably), the Boost Library Incubator. or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Waiting your reviews! Ion

13 51

[review] Review of Nowide (Unicode) continues - summary of the dicussions so far
by Frédéric Bron 15 Jun '17

15 Jun '17

Dear all, The formal review of Artyom Beilis' Nowide library continues until Wed. 21st of June. Here is a summary of the discussions so far: 7 people participate to the review (not counting Artyom and my-self): - Degski - Niall Douglas - Paul Groke - Peter Dimov - Vadim Zeitlin - Yakov Galka - Zach Laine 2 official reviews have been shared, both positive for inclusion in boost (Degski, Peter Dimov). Discussions: Everybody is positive about the usefullness of the library but some major questions arose: 1. how should we handle invalid Unicode sequences (bytes or multi-bytes)? Allow? throws error? 2. there is an unsymmetric way of treatment between Windows and Posix: - on Windows, the conversion from UTF-16 checks for Unicode conformance and returns only valid UTF-8 or fails - on Posix, no check is performed that the input is a valid UTF-8 sequence. 3. in particular, on Windows, the roundtrip conversion UTF-16 -> UTF-8 -> UTF-16 is not guaranted if the initial string is non conformant One main issue is that existing files may have non conformant names and would therefore not been reachable by the nowide API on Windows. On Posix platforms, non conformant paths would work transparently. Different proposals have been made to address this: - convert from UTF-16 to a superset of UTF-8 so that the round-tip conversion is possible, this would mean that the library accepts non conformant strings on Windows as is done on Posix. Question: which enconding should be used (Modified UTF-8, WTF-8, CESU-8)? WTF-8 has the issue of being difficult to handle with string concatenations. - use RtlUTF8ToUnicodeN functions which replace wrong UTF-16 characters by U+FFFD but is this OK for round-trip? - see glib approach - add function to explicitly convert from wide to WTF-8 However, for the Posix case, the issue is that we cannot guarantee that the encoding is always UTF-8 so checking for conformance may be impossible. Hence the choice for not checking on Posix. Minor points: - Missing some documentation on what happens if invalid UTF-8 is provided (getenv, setenv, cout, cerr). - ::setenv on cygwin gives a compile time error (Peter Dimov proposed a fix) - suggestion to add stat and readdir Frédéric

1 0

Packt: Mastering Git - Jakub Narębski
by degski 15 Jun '17

15 Jun '17

To those interested. On Packt, the ebook Mastering Git - Jakub Narębski <https://www.packtpub.com/application-development/mastering-git> is today avaialble for free download, free membership (registration) required. I don't work for Packt. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 0

[poly_collection] Help with Intel 16.0
by Joaquin M López Muñoz 14 Jun '17

14 Jun '17

Hello, Boost.PolyCollection will be released with Boost 1.65 on Aug 9. So far regression tests are looking OK for MSVC>=14.0, GCC>=5.0 and Clang>=3.7: http://www.boost.org/development/tests/develop/developer/poly_collection.ht… For Intel>=16.0, though, all tests pass except test_algorithm (admittedly the one involving more complex code): http://tinyurl.com/ya52o3e5 As I don't have local access to that compiler it is very difficult for me to try to find the needed workarounds. If someone with interest in Intel and access to the tools wants to volunteer to help fix the offending test case, please be my guest. Contact me either through this list or by private email. Thank you, Joaquín M López Muñoz

1 0

Mangled "From" field in mailing list posts
by Vladimir Prus 14 Jun '17

14 Jun '17

Hi, it seems that most of recent posts to the mailing lists have rather strange "From" field, e.g. From: Daniel James via Boost <boost(a)lists.boost.org> I see this problem both via NTTP and regular mail, including emails that appear to be posted directly with a mail client. That extra "via Boost" adds no value, and clutters mailbox. Is there any change to return back to having "From" field have just the name of the person? Thanks in advance, Volodya

7 18

[trac] Add Boost.Process to Boost.Trac component list
by Ion Gaztañaga 13 Jun '17

13 Jun '17

Hi, I recently received a bug report for Boost.Process. Since it is not selectable in the component list the reporter selected "interprocess" which minimizes the error ;-) Could someone with permissions add "process" to the trac component list? Many thanks! Ion

3 2

[beast] Request for Discussion
by Vinnie Falco 12 Jun '17

12 Jun '17

Beast provides low level HTTP and WebSocket interfaces built on Boost.Asio, the project is here: https://github.com/vinniefalco/Beast The plan is to solicit feedback from the Boost community before submitting a request for a formal review. First a brief update: I have attended CppCon 2016 and provided a 15 minute Lightning Talk on the library. There should be a video up at some point with all the talks, including mine. I spread the word about Beast and discovered that there are several folks in the wild already using the library and happy with it. There are also a couple of commercial products that are using it. One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. It is my idea to offer the building blocks (serializing and deserializing HTTP/1 messages, in synchronous and asynchronous flavors, and a universal HTTP message model), upon which other developers more knowledgeable than me could build those interfaces. The higher level pubic operations requested were: 1. Perform HTTP GET or POST and receive the response. Presumably this would handle both plain and TLS connections, handle redirects, and handle HEAD requests. Not sure about traversing proxies. 2. Expose an asynchronous HTTP server class which callers can instantiate with some sort of handler that returns the HTTP response given a request. It should be possible, in a minimal number of lines, to quickly get a server up and running. The requestor informed me that this functionality did not need to provide every possible feature or handle every use case. It just needed to handle the common use-cases. For the record, I am against this higher level functionality for a number of reasons. The higher the level of functionality, the more contentious the feature becomes, and the harder it is to satisfy a quorum of reviewers. No one would dispute that we need the ability to read a complete HTTP message from a socket. But not everyone will agree that a HTTP server needs an option to allow multiple listening sockets with different level of permissions. Another problem with offering higher level functionality is that it could be less likely to be approved for standardization in the C++ standard library. For example, the attributes of ease of use and fully functional oppose each other. If the functionality offered by a hypothetical std::http::client is not sufficient, a developer would be forced to write their own with little possibility to reuse parts of the implementation from the stdlib. I doubt the committee would approve of such a thing. I know I wouldn't. Admittedly I have little experience or knowledge on what would or would not get approved. A point was raised that a low-level-only HTTP implementation in Boost has the potential to discourage new users that need to perform simple operations like HTTP GET from using Boost in the future, given that robustly handling such operations would require the developer to write a significant amount of code. I can see some validity here. On the other hand, if Boost.Asio was submitted for a formal review today, would those same points be raised? Would Asio get rejected because it doesn't offer public interfaces for doing simple tasks like requesting an object from a web server? I wonder if perhaps the Boost formal review process has become defective. For reference here is what the current API offers: Example program that performs HTTP GET, then receives and prints the response: https://github.com/vinniefalco/Beast/blob/master/examples/http_example.cpp This is a high performance asynchronous HTTP server that serves local files as static pages. It is not an official API, it is part of the examples. Users who want a server need to copy the source code and modify it to suit their needs: https://github.com/vinniefalco/Beast/blob/master/examples/http_async_server… My initial purpose for requesting this discussion is two-fold: 1. Determine the level of consensus on the issue that Beast needs to do more for HTTP than the lowest level of functionality (reading and writing messages). I'm open to hearing all arguments for and against. 2. Get feedback on what official public interfaces to higher level functionality might look like. Specifically, a client that handles GET and POST, and a generic asynchronous server. And what features those interfaces would support. For example, is traversing a proxy a necessary feature for an official client interface? The best answers would provide function signatures or class declarations using the existing Beast HTTP types. In case its not clear, I am asking stakeholders and reviewers to help design the library. I'll open a discourse on the HTTP client to illustrate the proposed style of discussion: We want to provide a HTTP client implementation that lets users perform simple tasks like fetch a resource from a remote host. Calling code should be compact, letting people get their job done without getting mired in boilerplate. Here's a possible signature with example use: response_v1<string_body> get(std::string const& url, error_code& ec); error_code ec; auto res = get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; The get function would automatically perform the name resolution, connect the socket, request the resource with uri "/", and return the result. There's a problem here though, the caller is forced to use a message with std::string as the container for the body. An obvious fix is to add a template parameter: template<class Body = string_body> response_v1<Body> get(std::string const& url, error_code& ec); Better, but what if the body is not DefaultConstructible? We can add some parameters to forward to the Body constructor: template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); We're getting somewhere now. Most users will use the default body, while an option exists for advanced users. But the implementation of get now has a complication. If an error occurs, it still has to construct a return value. This problem is likely surmountable but lets table it and start a new line of reasoning. What if the URI indicates https, e.g. "https://boost.org"? We can hide that under the hood by using a separate code path that uses asio::ssl::stream instead of ip::tcp::socket. But how does the caller provide the root CA certificates? How does the caller provide a client certificate? We are left with a client that satisfies two thirds of users but is unusable for the remaining one third. Is this Boost worthy? Is this std-lib worthy? I think not. Lets revisit the SSL issues later and think about a new problem. What happens to the socket when the request is done? In the proposed interface, the socket is destroyed. This means you can only make one request on a connection. At this point, I think its clear that the current interface is a non-starter. Here's a better idea. Lets define a class called client and make get a member function. Now we can have state, including configurable settings with reasonable defaults. class client { public: template<class Option> void set_option(Option&&); template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); }; client c; error_code ec; auto res = c.get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; We still have some of the original problems, but other problems are solved. The class can keep the socket around, so that a subsequent call to get with the same server will use the already-open socket. The caller can set options on the client object instance before invoking get, such as any TLS certificates. Unfortunately we have new problems. Where is the io_service? If the class creates it for you, how many threads? How do I use my existing io_service, or is that even necessary? The class interface allows the connection to be kept alive but what if now the caller wants to close it (i.e. specify "Connection: close" in the request)? And there are some problems which are applicable to any interface. How does the caller adjust the parser options, for example change the limit on the size of the body? What if the caller wants the request made using a specific HTTP version? How does this handle basic authentication? How can the caller adjust the headers in the request? etc... This is why I think that offering a HTTP client is a rabbit hole which can only lead to a rejected formal review. Or maybe I am overthinking this? I'd love to hear proposed solutions to the issues (which could be just to say "forget about those features"). Despite my objection I have started work on these features anyway. Here are the beginnings of a HTTP client: https://github.com/vinniefalco/Beast/blob/88b485df7e6216282842f40cf99cc75de… Here is some work on a generic server: https://github.com/vinniefalco/Beast/blob/server/extras/beast/http/async_se… Please reply to this thread instead of starting a new thread, and keep the subject line prefix (e.g. "Re: [boost] [beast] ...") Thank you

21 58

Boost Build configure checks improvement. [config/predef]
by Rene Rivera 12 Jun '17

12 Jun '17

There's been a long standing "issue" with how the b2 configure checks work. Or rather how some times they don't work. In particular the issue is that the set of properties considered relevant for the configuration checks was fixed. As of last night that is now resolved < https://github.com/boostorg/build/commit/450c25c3b52f5ddcb323140f8423adf3b8… >. As the commit mentions the set is no longer fixed and is configurable by users. The changes now mean that: 1. Any subfeatures of the top level relevant feature set are also considered as part of the set. This means that one can a configuration like below to support multiple invocations of the same toolset with different options. In particular the STD options: === user-config.jam === import feature ; using clang ; feature.subfeature toolset clang : std : cxx03 cxx11 cxx14 cxx17 : optional composite propagated ; feature.compose <toolset-clang:std>cxx03 : <cxxflags>-std=c++03 ; feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; === And one can then invoke "b2 toolset=clang-cxx14,clang-cxx11" and get non-colliding configuration checks. 2. The set of relevant features is now soft wired as the set of subfeatures of the "<composite>" feature. Which means ones can add to the default set < https://github.com/boostorg/build/blob/develop/src/build/configure.jam#L26>. For example to add threading choice to the relevant features: === user-config.jam === import feature ; import configure ; feature.compose <configure> : <threading> ; === Enjoy. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[outcome] Second high level summary of review feedback accepted so far
by Niall Douglas 11 Jun '17

11 Jun '17

Firstly thanks to everyone who has contributed no less than **618** emails at the time of writing to the Outcome review. Despite some on Reddit calling this review a "train wreck" and indeed some lovely things about me personally, I have found this review deeply helpful, and I believe so have most of its contributors in helping us all firm up our differing opinions about what such a vocabulary type ought to be. With regard to the previous high level summary at http://boost.2283326.n4.nabble.com/outcome-High-level-summary-of-review-fee…, I have made only these changes to the changes in that summary: 1. I have been persuaded to use longer more appropriate naming for result<T> and outcome<T>, so now the typedefed varieties with implicit conversions to their empty-capable form indicated by "=>" are: - static_checked_outcome<T> => static_checked_optional_outcome<T> static_checked_result<T> => static_checked_optional_result<T> These have narrow observers which reinterpret_cast and are therefore undefined behaviour if the state does not match, but use __builtin_unreachable() to help static analysis tooling like clang-tidy spot UB where it can be statically deduced. Conceptually, they are a very thin convenience wrap of std::variant<...>. - runtime_checked_outcome<T> => runtime_checked_optional_outcome<T> runtime_checked_result<T> => runtime_checked_optional_result<T> The runtime_checked_optional_* varieties are identical and unchanged to the outcome<T> and result<T> in the submitted library. They have wide observers with a formal empty state and it is never undefined behaviour to call any observer. This allows the programmer to save typing considerable boilerplate knowing that the runtime checks save the programming needing to spell things out. I have not been persuaded to change a single thing in their design yet apart from removing unnecessary member functions, but thanks to everybody who has tried, and if you think I am making a critical mistake, you still have a few days left to persuade me of it! For anyone not familiar with the discussion and feels that the names are excessively long, be aware they are just convenience typedefs of a more complex to configure "template<...> class outcome_impl". It is expected that end users of the library will choose the varieties they want for their code and typedef them into their local namespace as "result<T>" or whatever. Nobody is proposing that end users actually type out the full name each and every time they use them, and the documentation will make that clear. 2. I have been persuaded to replace the implicit conversion from static_checked_* varieties to runtime_checked_* varieties with explicit conversion instead as the implicit conversion could produce runtime failure where the programmer did not expect that to occur. Regarding other changes that I have accepted since the previous high level summary: 1. Outcome's STL exception throw catch to result<T> super-macro was found to be overkill given that current compilers won't replace simple throw...catch sequences with a branch, and still invoke the full throw-catch runtime machinery whatever the case. Therefore an exception to error code conversion function makes more sense than a macro. https://github.com/ned14/boost.outcome/issues/50 2. Outcome's usage of git submodules is felt by some reviewers to be a showstopper for acceptance as they could bring in non-Boost code unexpectedly in the future. I have agreed to make a cronjob script generated Boost.Outcome from standalone Outcome in the same fashion as Boost.ASIO is script generated from standalone ASIO. https://github.com/ned14/boost.outcome/issues/51 - Licensing to be BSL only - No cmake, just bjam - No git submodules at all - std-flavoured, not boost-flavoured - No code to be brought in except that written by me i.e. a hardcoded whitelist applies. - Contents of Boost repo to only contain material directly relevant to Boost. Nothing else. 3. Under the assumption that error_code_extended's use of a static global ring buffer would be controversial in this review, I hacked a quick and dirty solution expecting to have to remove it. Now we know that few disapprove, a more serious implementation will be needed. https://github.com/ned14/boost.outcome/issues/52 4. Given where Vicente appears to be heading next with expected<T, E1, E2, ...> it may be wise to make the static_checked_* varieties use std::variant<...> for storage when being compiled on C++ 17. https://github.com/ned14/boost.outcome/issues/53 Thanks, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 52

[sort] Timsort review reminder
by Steven Ross 11 Jun '17

11 Jun '17

The review for C++ Timsort in Boost is ongoing and will continue through June 12. I am the review manager. The code can be found here: https://github.com/boostorg/sort/pull/12 To merge it into a local copy of the Boost.Sort library: git checkout -b ZaMaZaN4iK-feature_branch/TimSort develop git pull https://github.com/ZaMaZaN4iK/sort.git \ feature_branch/TimSort If you want to see a proposed version of the Sort library source with Francisco's changes and Timsort included, download the zip file <https://drive.google.com/file/d/0B4s-GPKYVV0jOGx5ckJUTkZzMWM/view?usp=shari…>. Feel free to compare flat_stable_sort with Timsort. Please answer these questions in reply to this thread: 1. What is your evaluation of the Timsort implementation? 2. What is your evaluation of the comments? 3. Did you try to use the library? With what compiler? Did you have any problems? 4. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 5. How familiar are you with the details of hybrid and stable sorts? 6. Would you actually use Timsort if it was in Boost.Sort? If so, how is it better than the next best alternative? 7. Do you think Timsort should be included in Boost.Sort? Please ask Alexander Zaitsev any questions you have about Timsort for this review before submitting your final review. Thanks, Steven Ross

11 19

[static_views] [gsoc17] Proposal for a library
by Tom Westerhout 10 Jun '17

10 Jun '17

Hi! I'm Tom Westerhout, one of this year's GSoC interns. The module I'm planning to work on, StaticViews, is essentially a subset of Ranges TS optimised for usage with compile-time homogeneous datasets. It can be used to implement compile-time associative maps, compile-time checking of non-type constraints, and compile-time generation of datasets from other compile-time datasets. Some more explanation and motivating examples are on this page: https://boostgsoc17.github.io/static-map/doc/123_build/html/getting_started… Do you think this would be a worthwhile addition to Boost? Is the choice to use Ranges TS as inspiration for the API wise, or would a different API (please, suggest one) be better? All comments are welcome. Thanks in advance! Tom

2 1

Repeated super project commits
by Daniel James 10 Jun '17

10 Jun '17

Hi, You might noticed that some of today's super project commits were repeated. I was working on a change to do one commit per push event, and it went a bit wrong. It turns out there was an existing bug, which meant the script wasn't always updating the position in the event queue. I fixed it while writing the new version, but assumed it was a new bug that I'd introduced today. So when the new version started, it replayed the events since the position was last updated. I backed out the change and I'm going to try to make the script a bit more robust before changing it again - even without the bug, a similar thing could happen if someone manually updated a submodule in the super project. Because the commits were all in a single push, and the last commit was correct, it shouldn't cause any real problems, but there are a few wonky commits in the history, so sorry about that. Because of the way the script worked, the bug only affects that batch of commits, older commits are fine. Daniel

1 0

Re: [boost] [Boost-testing] [EXTERNAL] Run.py test failure 'minimal' is an invalid property
by Tom Kent 10 Jun '17

10 Jun '17

On Wed, Jun 7, 2017 at 10:39 PM, Belcourt, Kenneth via Boost-Testing < boost-testing(a)lists.boost.org> wrote: > Hi, > > To followup with more info on this issue, testing is broken on master when > building on the Mac, though not sure why. Here’s what works okay: > > python run.py --tag=develop --runner="Sandia-clang-3.8" > --toolset=clang-darwin --pjl-toolset=darwin --bjam-options="-j8” > > and what fails (same command with —tag=master): > > python run.py —tag=master --runner="Sandia-clang-3.8" > --toolset=clang-darwin --pjl-toolset=darwin --bjam-options="-j8" > > The error from the failed master build is the error below. It seems to be > related to the context library use of alias (highlighted below). Are there > perhaps boost build or context changes that need to be merged to master > into order to fix this issue? From what I can tell, testing master on > MacOS is hosed. > > Noel > > > On Jun 7, 2017, at 6:03 PM, Belcourt, Kenneth via Boost-Testing < > boost-testing(a)lists.boost.org> wrote: > > > > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/property.jam:529: > in property.translate from module property > > error: 'minimal' is not a valid property specification > > /Users/jenkins/slave/workspace/build-tpls/boost_bb/ > src/build/property-set.jam:432: in property-set.create-from-user-input > from module property-set > /Users/jenkins/slave/workspace/build-tpls/boost_bb/ > src/build/property-set.jam:484: in property-set.refine-from-user-input > from module property-set > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/targets.jam:1619: > in targets.main-target-requirements from module targets > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/alias.jam:65: > in test-suite from module alias > *../libs/context/test/Jamfile.v2:97: in modules.load from module * > Jamfile</Users/jenkins/slave/workspace/build-tpls/boost_ > root/libs/context/test> > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:325: > in load-jamfile from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:64: > in load from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:145: > in project.find from module project > Jamfile.v2:118: in run-tests from module Jamfile</Users/jenkins/slave/ > workspace/build-tpls/boost_root/status> > Jamfile.v2:171: in modules.load from module Jamfile</Users/jenkins/slave/ > workspace/build-tpls/boost_root/status> > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:325: > in load-jamfile from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:64: > in load from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:145: > in project.find from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build-system.jam:535: > in load from module build-system > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/kernel/modules.jam:295: > in import from module modules > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/kernel/bootstrap.jam:139: > in boost-build from module > /Users/jenkins/slave/workspace/build-tpls/boost_root/boost-build.jam:17: > in module scope from module > > I see the same error for master on linux and windows runners. Tom

5 10

[review] **NEXT WEEK** Review of Nowide (Unicode) Mon. 12th -> Wed. 21st June
by Frédéric Bron 10 Jun '17

10 Jun '17

Hi Everyone, ** HEADS UP, NEXT WEEK'S REVIEW ** The formal review of Artyom Beilis' Nowide library starts next week (Mon. 12-June to Wed. 21-June). Your participation is encouraged, as the proposed library is uncoupled and focused. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarball: get it from GitHub (Download as zip) NEXT WEEK (when the public review is started): Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

2 1

[Format] User-defined literals for Boost.Format
by Корсунов Игорь 09 Jun '17

09 Jun '17

1 0

Re: [boost] [property_tree] Issue: erase is corrupting the tree
by lukas.exler＠barclays.com 09 Jun '17

09 Jun '17

The minimal code that crashes is: boost::property_tree::ptree loadedJSON; boost::property_tree::read_json("animalList.json", loadedJSON); auto assoc_it = loadedJSON.find("animals"); auto it = loadedJSON.to_iterator(assoc_it); it = it->second.begin(); it++; // move to second item loadedJSON.erase(it); boost::property_tree::write_json("shorterList.json", loadedJSON); Where content of "animalList.json" file is: { "animals" : ["fox","dog","cat"] } -----Original Message----- From: Mert Büyüktuncay [mailto:mert.buyuktuncay@sestek.com] Sent: Tuesday, June 06, 2017 9:22 AM To: boost(a)lists.boost.org Cc: Exler, Lukas: IT (PRG) Subject: RE: [property_tree] Issue: erase is corrupting the tree This mail originated from outside our organisation Do you use "it" iterator after the call to erase in that case you shall use it = loadedJSON.erase(it); instead of it++ If this is not your problem you can share a little more code for us to see in detail what is happening here. May be the code up to the point where "write_json" is being called. Regards Mert -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Lukas via Boost Sent: Monday, June 5, 2017 4:08 PM To: boost(a)lists.boost.org Cc: lukas.exler(a)barclays.com Subject: [boost] [property_tree] Issue: erase is corrupting the tree I have following JSON structure loaded into boost::property_tree: { "animals" : ["fox","dog","cat"] } I'm trying to delete the second item from the array by: auto assoc_it = loadedJSON.find("animals"); auto it = loadedJSON.to_iterator(assoc_it); it = it->second.begin(); it++; // move to second item loadedJSON.erase(it); After this, when I try to use boost::property_tree::write_json to write the JSON back the app crashes. Do I use the property tree in a wrong way, or is there a bug? Thanks, Lukas. _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Bu elektronik posta mesajı ve ekleri sadece gönderildiği kişi veya kuruma özeldir ve gizli bilgiler içerebilir. Eğer bu mesajı hataen aldıysanız lütfen bu durumu gönderen kişiye derhal bildiriniz ve mesajı sisteminizden siliniz. Eğer doğru kişiye ulaşmadığını düşünüyorsanız, bu mesajın gizlenmesi, yönlendirilmesi, kopyalanması veya herhangi bir şekilde kullanılması yasaktır. Internet iletişiminde güvenlik ve hatasız gönderim garanti edilemeyeceğinden, mesajın yerine ulaşmaması, geç ulaşması, içeriğinin bozulması ya da mesajın virüs taşıması gibi problemler oluşabilir. Gönderen taraf bu tip sorunlardan sorumlu tutulmaz. SESTEK Ses ve İletişim Teknolojileri A.Ş. www.sestek.com<http://www.sestek.com> This e-mail message and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, please notify the sender immediately and delete it from your system. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is prohibited. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission SESTEK INC. www.sestek.com <http://www.sestek.com> Bu elektronik posta mesajı ve ekleri sadece gönderildiği kişi veya kuruma özeldir ve gizli bilgiler içerebilir. Eğer bu mesajı hataen aldıysanız lütfen bu durumu gönderen kişiye derhal bildiriniz ve mesajı sisteminizden siliniz. Eğer doğru kişiye ulaşmadığını düşünüyorsanız, bu mesajın gizlenmesi, yönlendirilmesi, kopyalanması veya herhangi bir şekilde kullanılması yasaktır. Internet iletişiminde güvenlik ve hatasız gönderim garanti edilemeyeceğinden, mesajın yerine ulaşmaması, geç ulaşması, içeriğinin bozulması ya da mesajın virüs taşıması gibi problemler oluşabilir. Gönderen taraf bu tip sorunlardan sorumlu tutulmaz. SESTEK Ses ve İletişim Teknolojileri A.Ş. www.sestek.com<http://www.sestek.com> This e-mail message and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, please notify the sender immediately and delete it from your system. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is prohibited. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission SESTEK INC. www.sestek.com <http://www.sestek.com> _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________

2 1

What is the process for adding a library suggestion?
by Adrian H 07 Jun '17

07 Jun '17

I have a suggestion for adding something to the boost library. It is simple but I believe that it would be useful. Do I just post it here or is there some process? Thanks, A -- ======================================== Adrian Hawryluk BSc. Computer Science ---------------------------------------- Specialising in: OOD Methodologies in UML OOP Methodologies in C, C++ and more RT Embedded Programming GUI Development ========================================

3 2

svn.boost.org schedule maintenance - DOWN TIME
by Michael Caisse 07 Jun '17

07 Jun '17

Hi all - svn.boost.org is scheduled for maintenance on June 8 from 1700 - 1900 UTC. Expect outages for Trac during this time. Happy coding! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[review] Outcome Review Report
by charleyb123 . 07 Jun '17

07 Jun '17

# Boost.Outcome REVIEW REPORT In conclusion to the Outcome Library Review (19-May to 02-June, 2017): The library is REJECTED. Rejection is principally due to: (1) Unresolved key behavior at conclusion of the review period (2) Misunderstanding/disagreement regarding library’s intended purpose (3) Unclear precedent/implications from accepting this library in its current configuration into the Boost distribution The following weighed heavily to consider accepting the library into Boost: (a) The library demonstrates solutions to fundamental issues (error and exception handling) (b) The library effectively addresses constraints to serve the needs of several user-bases (c) New paradigms/idioms are enabled (d) Implementation is of high quality Some 20+ participants sent 850+ email messages to the public list discussing the Outcome library, plus additional (non-trivial) off-list discussion. Public reviews sent to the list were from: *- Paul Bristow -- ACCEPT (Tue-23-May) *- Deniz Bahadir -- ACCEPT (Wed-24-May) *- Robert Ramey -- REJECT (Fri-26-May) *- Peter Dimov -- REJECT (Sun-28-May) *- Emil Dotchevski -- REJECT (Sun-28-May) *- Vicente J. Botet Escriba -- REJECT (Tue-30-May) *- Andrzej Krzemienski -- REJECT (Wed-31-May) *- Gavin Lambert -- REJECT (May 31) *- Bjorn Reese -- REJECT (Fri-02-June) The remainder of this report is a summary of discussion with select issues specific to the Outcome library, plus some possible topics for further consideration by the Boost Community and Boost Steering Committee. This further elaboration is not intended to be comprehensive regarding issues raised during the review; Rather, it is to: (a) Provide historical “summary/context” for the level of discussion exhibited during this review, and which contributed to the final decision; (b) Highlight issues that may provide assistance in considering “readiness” for a later review for an evolved form of this library (or for a similar library intending to address the same domain); (c) Provide “discussion-points” for the Boost Community and Boost Steering Committee regarding possible future evolution or guidance associated with Boost tooling, distribution, and individual library dependencies (related to topics raised during this review). The conclusions will be: (1) Outcome Library Author: Consider re-submitting for review when... (a) Key behavior/design issues are resolved (see below) (b) Integration plan with Boost is more clear (and consistent with Boost Steering Committee Guidance) (2) Boost Community / Boost Steering Committee: Consider providing guidance to future library submissions regarding... (a) Attempted dual-license, this submission attempted: *- BSL+Apache2 dual-license (b) “Extra-build-steps”, this submission attempted: *- Custom preprocessing to “generate-source” (to significantly improve compile-time speed) (Note: During review, a template-based solution was proposed as a possible replacement mechanism, but code-gen should probably be explicitly addressed) (c) Class/namespace versioning, this submission attempted: *- Stable ABI/versioning mechanism through a framework provided with this submission (to enable multiple versions of this library used by differing third-party libraries to correctly coexist within the same binary) (d) Use of outside source; use of git (git-submodules), this submission attempted: *- Dependency to an outside (git-submodule) lib archive (gsl-lite: https://github.com/martinmoene/gsl-lite.git ) (e) Use of (non-test/Jamfile) for test, this submission attempted: *- Custom test mechanism (because “Boost.Test” won’t work with C++ exceptions disabled; lib needed “boost-lite” to run the test suite) (f) Use of CMake, Dependency upon Boost, this submission attempted: *- No Boost dependency (but provided a “boost-lite” shim to coexist in user-workspaces with-or-without Boost, providing common cmake machinery and test-running) # SUMMARY OVERVIEW As demonstrated through the volume and depth of discussion, the library attracted wide interest, which is consistent with a perception that it attempts to address an active need. Comments suggested the library’s purpose (enabling public APIs to pass <value|error|exception>) was useful, and that enabling a shared handling of <error|exception> to be somewhat novel. Several participants further suggested that the library attempts to serve a role as a “fundamental” library: to provide vocabulary types and pose new idioms, to be used in public APIs as a common <error|exception> exchange mechanism. One reviewer commented that the library’s documentation under-sold the library’s motivation, suggesting it compelling for: *- Cases where errors cannot be propagated by throwing exceptions (e.g., within callbacks where an error value is provided [e.g., ASIO]); *- When passing values between threads, such as in an Actor model where a message queue handles return values (e.g., pass outcome<T> instead of an std::error_code to handle <error|exception> in addition to desired <T>) Many/most reviewers that voted REJECT commented that they would like a similar library to be accepted, or perhaps an evolved form of this library after necessary changes (see below). To accept the importance of the domain which the library attempts to address, one need not agree with the design nor implementation of Outcome (indeed, the library is rejected in its current form at the conclusion of this review). Rather, this summary assertion is that the Outcome proposal successfully demonstrates a need for such a fundamental (and community-endorsed) solution (or direction) for error handling. # ISSUE: Unresolved key behavior at conclusion of the review period Key behavior (or design) issues that did not reach consensus by the end of the review period: (1) Narrow vs. Wide contracts -- consensus is not reached (2) Empty-state (allowed?) remains controversial (3) Ring-buffer appears uncontroversial; but perhaps needs additional scrutiny (a) Separate library implementation (for reuse elsewhere, and to enable evolution without touching the ‘result<>’/’outcome<>’ API)? (b) Bigger buffer? Some of the difficulties in this evaluation likely trace to the (in-progress) evolution of the proposed ‘std::expected<>’ (also discussed during this review). A future Outcome review would likely benefit from the clarity provided by fully resolved semantics for ‘std::expected<>’. # ISSUE: Misunderstanding/disagreement regarding library’s intended purpose The Outcome library attempts to define a paradigm and propose idioms in <error|exception> handling, where few can successfully argue that current practice, libraries, and idioms are sufficient. The review concluded that Outcome proposes a new paradigm that is demonstrated to be useful and effective. However, disagreement exists on the nature of that framework: PURPOSE: Outcome is a unified/universal <error|exception> handling framework for use in public APIs; (a) ...enabling user-customization to address domain-specific constraints ...versus... (b) ...for possible future consideration in a C++ Standards Track, likely within <system_error> The Library Author intended (a), while multiple reviewers advocated for (b). This disagreement-in-vision resulted in many difficult discussions during the review, and ultimately lack of consensus for several important API and design decisions (due to the corresponding implied future limitations). For example: Static-checked vs. Runtime-checked behavior. The library-as-presented attempts to serve both, citing orthogonal user bases with differing (latency) constraints, such as “with-or-without” runtime overhead, and “with-or-without” Undefined Behavior (UB). Current implementation enables integration of arbitrary third-party libraries (each with their own preferred error handling strategy and tradeoffs), with zero-cost conversion and inter-operation. However, this *significantly* complicates the design: The user composes ‘result<>’ and ‘outcome<>’ types with regards to module-specific static or runtime type safety and performance requirements, which (transparently) propagate through the library internals and across threads and public APIs to external modules. In contrast, a C++ Standards Track implementation is likely much simpler, introducing one-or-two vocabulary types merely parameterized on ‘<T>’, providing a simplified (and “standard”) mechanism to bridge <T|error|exception> transport across third-party module boundaries. For example, in advocating for a “Standards-Track” vocabulary type, reviewers argued for a mechanism that would enable user-libraries to obsolete the duplicate “throw/no-throw” APIs with a single API: R filesystem_api(); // throws filesystem_error R filesystem_api( error_code& ec ) noexcept; ...becomes... outcome<R> filesystem_api(); // <R|error|exception> The contrast between the two visions can more distinctly be termed: (a) “Multi-Modal” Usage -- Many varieties of usage style within the API is necessary, because there are a multitude of ways for library abstractions to be used in composition patterns due to domain-specific constraints (likely with some idioms not yet discovered, or not yet in widespread use) (b) “Single-Modal” Usage -- One (single) clean design and use model is encouraged The Library Author states that normal C++ design principles should prefer (b), but due to the vocabulary-type nature of the problem and domain-specific constraints encountered by real-world users, this particular library was forcefully evolved into (a). It is perhaps ironic that the suitability of a proposed library as providing vocabulary types and possibly evolving into a future standard demands that the Library Author change the library’s stated purpose due to this potential popularity; but that seems consistent with the current circumstance. The Library Author (of course) should have authority to characterize the actual intended use-case and resulting behavior provided through the authored work; with the Review Process providing analysis and feedback regarding possible missed opportunity resulting from those decisions. However, this review’s conclusion seems to encounter the curious scenario where the vision itself remains in conflict. Of course, these very differing outlooks resulted in some apparent “impasses” or circular discussions regarding type-safety (and number-of-types), wide or narrow contracts, optimization opportunities, “too-big” (or “cluttered”) interfaces, implicit or explicit conversion, the need for iterator and visitor patterns on ‘outcome<T>’, and the “empty” state and sentinel values. In support of the “Multi-Modal” design, the Library Author posits three main use patterns exist for error-handling objects-returned, and that a single design can serve only two at best: (Quoting the Library Author): > <quote> > (1) User wants failure reason type to be local to only the code to which > it applies. So think custom E type, nonconvertible to any other E type, and > E is never error_code nor exception_ptr. They specifically want to keep > failure handling local a small patch of code e.g. constexpr evaluation > contexts. > > All-narrow observers make sense for this use case as object usage is > tightly integrated to the code using it, and failure is handled entirely > locally. > > (2) User wants failure reason type to be globally understood and will be > choosing either E = std::error_code, or E = std::exception_ptr. They > specifically want failure handling to be able to traverse any or all code, > just like C++ exception throws. This is where Outcome was primarily aimed > at. > > All-wide observers make sense for this use case, as due to handling a wide > degree of uncertainty, most failure handling code is *generic* i.e. we test > for some specific failure causes, and for everything else we either ignore > or hand it off to other code to handle. > > (3) User wants to write functional programming logic using the basic > vocabulary of Maybe, Either and i/o monads and basic operators of bind, > fmap, do etc and probably some subset or refinement of Hana for the > collections monads, though my GSoC student may be making the Ranges TS a > choice here as well later this summer. > > All-narrow observers make sense for this use case as the monadic operators > ensure your function will never be called with the wrong state. > </quote> The Outcome library uses a, “single implementation, multiple personalities” to solve this problem, and makes the intentional decision to attempt targeting (2). # ISSUE: Unclear precedent/implications from including this library in its current configuration into the Boost distribution The library in its current configuration is perceived as setting precedent for changes to the Boost distribution, which reviewers commented added complexity to their analysis. Specific topics: *- Dual-license (BSL and Apache2) confused reviewers *- Add bjam support (author agreed) *- Packaging relied upon git-submodules to an outside lib archive (gsl-lite, https://github.com/martinmoene/gsl-lite.git) *- Library does tricks with the preprocessor to avoid significant compile-time costs; but these tricks were commented by some reviewers as being unnecessarily complex. *- The Author found these tricks necessary to reach reasonable compile metrics for large projects using Outcome in their public APIs, and believes some mechanism must address this build-speed-need. A proposed metaprogramming mechanism may eliminate the need for these preprocessor tricks in the future. # FINAL THOUGHTS In the very active years of “Classic Boost” (such as 2004-2008), fundamental libraries had a good chance of becoming vocabulary types that attempt to establish new Best Practice for the industry (and not merely be “just another library”). This awareness drove much of the review discussion, and underscored the importance of experimentation and “lessons learned” to result in a library that offered: (1) behavior and idioms that are understood; and (2) sufficient experience to make use recommendation to the wider user base in contrast to existing alternative approaches. Consistent with this historical context, it should be relatively uncontroversial to recognize that the Outcome library does not reach that threshold at this time (so it is rejected). However, this review also suggests: (1) A similar library is needed; (2) The community lacks agreement on direction (e.g., “Multi-Modal” vs. “Single-Modal”) In support of experimentation and to expand on our “lessons-learned”, it seems somewhat obvious that Outcome provides a strongly-implemented Multi-Modal low-latency library that will assist the community in gaining experience with these idioms proposed. Since conclusion of the review period, discussion continues (on and off-list) regarding possible evolution to the Outcome library, related to feedback provided during this review, and related to discussions of design evolution for pertinent libraries (e.g., possible changes to std::expected<>, and evolution of a never-empty ‘variant2<>’). It is promising that such a strong library as Outcome continues to receive critical attention and evolution by multiple interested parties. Great thanks to the Boost Community for their tremendous efforts, disciplined review, and detailed exploration of topics in considering this library submission. Sincerest appreciation to Niall Douglas (Author of the Outcome Library) for pushing the envelope for low-latency <error|exception> handling and for submitting his work to the Boost Review process. -- charley (Outcome Review Manager) If there be any in this assembly, any dear friend of Caesar's, to him I say that Brutus' love to Caesar was no less than his. If then that friend demand why Brutus rose against Caesar, this is my answer: not that I loved Caesar less, but that I loved Rome more. (3.2.19-24)

7 8

Deprecation indication
by Raffi Enficiaud 06 Jun '17

06 Jun '17

Hi, Is there anything in eg. boost.config or other that expands to a compiler indication that something is "deprecated", possibly with a message that appears only once? It may expand to `[[deprecated]]` or `[[deprecated("reason")]]` if available and supported, or `__declspec(deprecated)` / `__declspec(deprecated("reason"))`, `__attribute__ ((deprecated))` ... I could not find anything in boost.config. Has anyone an example of this in boost? Is there any indication/policy in boost about deprecation? Thanks in advance, Raffi

1 0

[Nowide] Links to source code
by Artyom Beilis 06 Jun '17

06 Jun '17

Hello Frederic and Boost Developers. I had noticed that the links to the source and git repository at http://www.boost.org/community/review_schedule.html are incorrect. It should be links to github https://github.com/artyom-beilis/nowide Can it be fixed before the review begins in order to prevent confusion? Thanks, Artyom Beilis

1 0

[outcome] High level summary of review feedback accepted so far
by Niall Douglas 05 Jun '17

05 Jun '17

Some reviewers have asked what form Outcome will take in the near future. The following is a high level summary of the changes already made on develop branch or will be made according to https://github.com/ned14/boost.outcome/issues logged from review feedback. I have left out some minor issues, this lists just the major changes. This should help reviewers to decide whether to recommend acceptance or rejection. If there are any questions, please do ask. Major design changes: ===================== - option<T> to be removed https://github.com/ned14/boost.outcome/issues/48 - outcome<T> and result<T> will have their empty state removed, and all observers gain narrow contracts. Default construction is disabled. https://github.com/ned14/boost.outcome/issues/44. Example: ``` result<Foo> v(make_errored_result(std::errc::invalid_argument)); assert(v.has_error()); // true assert(!v.has_value()); // true // As if Foo(reinterpret_cast<Foo &&> // (error_code_extended(std::errc::invalid_argument)); Foo f(std::move(v.value())); assert(v.has_error()); // still true assert(!v.has_value()); // still true ``` (NOTE: expected<T, E> will track whatever LEWG Expected does, but it differs from what will become result<T> by having a wide contract on .value() and narrow contracts on operator*(), .error(), operator->(). result<T> will have narrow contracts on everything, it is basically a thin wrap of std::variant<T, error_code_extended> except with strong never empty warranty) - New typedefs outcome_e<T> and result_e<T> are identical to outcome<T> and result<T> except for adding a formal empty state. Observer contract slightly widens, an attempt to use an empty object throws a bad_outcome_access exception. Implicit conversion from non-empty-capable varieties is permitted to empty-capable varieties, but not the other way round. Default construction is to **empty**. https://github.com/ned14/boost.outcome/issues/44 - New typedefs checked_outcome<T>/checked_result<T>, checked_outcome_e<T>/checked_result_e<T> are added. These mirror the editions just described, but checks and default actions occur on all observer usage so hidden reinterpret_cast<> never occurs. Implicit conversion from non-checked varieties is permitted to checked varieties, but not the other way round. https://github.com/ned14/boost.outcome/issues/47. Examples: ``` // Note result<T> implicitly converts to checked_result<T>, but not // the other way round. So we can use same make_errored_result(). checked_result<Foo> v(make_errored_result(std::errc::invalid_argument)); assert(v.has_error()); // true assert(!v.has_value()); // true // .value() throws std::system_error( // std::make_error_code(std::errc::invalid_argument)); Foo f(std::move(v.value())); ``` ``` checked_result<Foo> v(make_valued_result(Foo())); assert(!v.has_error()); // true assert(v.has_value()); // true // .error() returns a default constructed (null) error_code_extended // when result is valued to indicate "no error here" error_code_extended ec(std::move(v.error())); assert(!ec); // true ``` - The presented library self generates using lots of preprocessor based multiple #include's to stamp out finished editions of implementation. The git repo partially preprocesses this into a nearly finished edition for minimum compile time load for end users. Due to the many more varieties of outcome<T> and result<T> provided, the preprocessor machinery would be replaced with a template based machinery instead. I will look into making optional use of extern template and a static library to retain minimum compile time load, but header only usage will remain possible. Smaller design changes: ======================= - tribool stuff to go away in default configured build. https://github.com/ned14/boost.outcome/issues/22 - .get*() functions will be removed. https://github.com/ned14/boost.outcome/issues/24 - Don't include <windows.h> on winclang. https://github.com/ned14/boost.outcome/issues/39 Documentation changes: ====================== - Licence boilerplate missing on some files. https://github.com/ned14/boost.outcome/issues/38 - Reference API docs need to spell out exact preconditions, postconditions and semantics per API. https://github.com/ned14/boost.outcome/issues/26 - Reference API docs need to describe types void_rebound, *_type and raw_*_type in detail. https://github.com/ned14/boost.outcome/issues/29 - User overridable macros which throw exceptions and provide customisation points have vanished from the docs somehow. https://github.com/ned14/boost.outcome/issues/35 - Landing page and introduction to be broken up into bitesize single page chunks. https://github.com/ned14/boost.outcome/issues/41 Still to be decided: ==================== - Should *_e() varieties provide convenience .get(), .get_error(), .get_exception() which returns T, error_code_extended and std::exception_ptr by value moved from internal state, resetting state afterwards to empty? These would mirror future.get()'s single shot observers. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 104

DocBook toolchain: Disable auto toc for just one section's children?
by Vinnie Falco 05 Jun '17

05 Jun '17

My documentation has a reference section whose children are themselves sections automatically generated by a doxygen->xml->xslt->QuickBook chain. I want an automatically generated table of contents, but when I turn that on I get hundreds of entries for all of the individual classes and functions in the reference. Is there a way to disable just the child sections of my Reference section? Perhaps marking the section somehow and passing an xsl:param in the Jamfile or something? This would really help to put that last bit of polish on these docs. I noticed that Boost.Asio docs had the same problem, so the author just disabled the auto-toc and created a very small, manual one. Not the same. Ideas?

3 5

[property_tree] Issue: erase is corrupting the tree
by lukas.exler＠barclays.com 05 Jun '17

05 Jun '17

I have following JSON structure loaded into boost::property_tree: { "animals" : ["fox","dog","cat"] } I'm trying to delete the second item from the array by: auto assoc_it = loadedJSON.find("animals"); auto it = loadedJSON.to_iterator(assoc_it); it = it->second.begin(); it++; // move to second item loadedJSON.erase(it); After this, when I try to use boost::property_tree::write_json to write the JSON back the app crashes. Do I use the property tree in a wrong way, or is there a bug? Thanks, Lukas. _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________

1 0

[outcome] non-interface-related concerns
by Andrzej Krzemienski 05 Jun '17

05 Jun '17

The discussion mostly revolves around the design of the interface of `outcome::expected` and even `std::expected`. My questions here are about the way this library will be distributed to users. And I am uncomfortable with the situation. I am not necessarily saying it is wrong, but I do not understand what is going on here. 1. The current GitHub repository consists of sub-repos. Do you (Niall) plan to have it like this when the library is accepted? Is it relevant? 2. This macro BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE, it controls whether I use this "preprocessed" file versus if I use... what? Normal header files? What is gained by this preprocessed file? Not having to include more than one header, or something else? Can I get different results when compiling with and without this macro? 3. I am recommended to use this macro BOOST_OUTCOME_V1_NAMESPACE. I am told it has something to do with ABI stability? Can you elaborate on how this guarantees ABI stability. Or is its purpose different? I have a certain problem with understanding this philosophy. A couple of days back, I reported the compilation failure in MinGW. I can see that the issue (https://github.com/ned14/boost.outcome/issues/36) is reorted as fixed in branch 'develop'. I would like to confirm that the bug is fixed. I checkout branch develop. There is no branch develop for the sub-repos, so what am I supposed to checkout, master, or some particular commit? I went with master. I do not understand a lot of CMake, but since it is a header-only library, I assume that I can just #include the file "include/boost/outcome.hpp", and my programs (compiled manually) should compile. But the only change in the commit that was supposed to fix the bug, was in a .cmake file, so I cannot see how it would help fix a header only library. Also, would the fix be visible in a "precompiled" header, or normal headres, or both? I am not complaining about this particular fix. I would like to know how in this system of mcros, sub-modules and preprocessed headers, I can figure out what changes will be observed in my program, when I see a particular change in git sub-repo. Regards, &rzej;

10 42

[outcome] Review
by Bjorn Reese 03 Jun '17

03 Jun '17

I apologize in advance for the rather meek review below; I did not have the time to be more thorough. > - What is your evaluation of the design? The review discussions provided many insightful arguments in favour or against various aspects of the design, and I have not formed a final opinion about most of these. I do believe that fixing E for result<T> to error_code is the right decision. I would prefer a design without an empty state, because we already have a vocabulary type for it. The choice of C++14 seems motivated solely by performance considerations. A slower C++11 version should be considered. > - What is your evaluation of the implementation? I did not have enough time to review it. > - What is your evaluation of the documentation? The introduction (Description) only provides a vague description of the purpose of the library. For example, it does not mention that its types are used to carry either a value or an error. Instead, it assumes that the reader can derive this from prior familiarity with expected<T> (or Rust.) The first motivating example is too large (as indeed are the examples in the tutorial.) Instead I suggest a "Tony table" that shows the essense of the library (either value or error.) For example: Before: FILE *file = fopen("myfile", "r"); if (!file) throw std::system_error(errno, std::system_category(), "Error delivered out-of-band by errno"); fclose(file); After: result<FILE *> file = fopen_wrapper("myfile", "r"); if (!file) throw std::system_error(file.error(), "Error delivered in-band by file.error()"); fclose(file.value()); This may not look overly convincing, but it does demonstrate the either value or error aspect in a few lines. The library is weakly motivated -- the motivation boils down to a less expensive alternative to throwing exceptions. A stronger motivation would have been to mention use cases were errors cannot be propagated by throwing exceptions. Here are two examples: One motivating use case where exceptions cannot be throw are callbacks, such as Boost.Asio asynchronous handlers. Here the return value is not returned by the asynchronous operation (the initiating function), but will be passed to the provided callback once the operation completes. In other words, the following synchronous operation return_type operation(arg_type, error_code&); is turned into this asynchronous operation: void async_operation(arg_type, void (*)(return_type, error_code)); Exceptions cannot be thrown into the functions (here the callback), so errors have to be passed as arguments (whether error_code or exception_ptr.) The above works if the return_type has a reasonable "unengaged" value that can be passed as the first argument in case of an error. While this is true for Boost.Asio, where return_type is a std::size_t, it is not necessarily true in general. A much better solution is to pass an outcome<T>, result<T>, or expected<T>: void async_operation(arg_type, void(*)(result<result_type>)); Another motivating use case is passing results between threads. For instance, in the Actor model of concurrency information is passed between actors/threads via a message queue. Some of these messages are replies to requests that may or may not have failed. A queue containing one of the Outcome types is well-suited for this kind of interaction. Apart from the above-mentioned shortcomings, I found the remainder of the documentation quite readable. I did not find the inheritance diagrams in the reference documentation useful though. > - What is your evaluation of the potential usefulness of the library? The idea of an either-value-or-error return type is very useful. > - Do you think the library should be accepted as a Boost library? No, not in its current form. I have two reasons for this rejection. First, some of the design discussions (especially on narrow/wide contracts) are not settled yet, so it would be premature to vote for the design. Second, whilst the lastest offer from the author about a fully-fledged Boost.Outcome repository without a dependency on the non-reviewed library called "boost-lite" is a step in the right direction, it is unclear to me how that repository will end up. Having been surprised by the current submission and the author's opinions, I will defer any vote of acceptance until the a repository is submitted for review.

2 2

[outcome] expected, etc. why are these assignable
by Robert Ramey 03 Jun '17

03 Jun '17

It just occurred to me that for a similar component I created some time ago for my own purposes, I (intentionally?) support of the assignment operator. Copy construction was permitted however. So the only way to use the component is: checked_result<int> = function(...); something void function(checked_result & cr, ....) will be the same as void function(const checked_result & cr, ...) because checked_result only contains const functions. That is, once constructed, it's immutable. Personally I never use an interface which passes a mutable type to a function. To me it violates the mathematical idea of what a function is. Doesn't this simplify things? Doesn't this eliminate the whole questions about about empty state, etc. Doesn't this better model the "mondad" concept we're trying to leverage on. And why the hell are we modifying and an object designed to model a result in the first place? It doesn't make logical sense in terms of we expect a "result" to be. I plunk down my money (a function) and ask for a pepperoni pizza. Either they say they don't have pepperoni and give me my money back or give me a pizza. I don't think of modifying this result - it's an artifact of history. And wouldn't making these things immutable, eliminate a large part of the whole controversy? Just a thought. I think sometimes something is hard because we haven't thought enough about what we're really trying to do - what problem we're trying to solve. Robert Ramey

6 16

[outcome] To variant, or not to variant?
by Gavin Lambert 03 Jun '17

03 Jun '17

I probably should have thought of asking this earlier, but it occurs to me now that my own mental model of how an "outcome"-ish type should act is probably not suited to variant storage at all. So just out of curiosity I thought I'd ask whether people prefer this sort of interface: template<typename T> class outcome { public: bool has_value() const { return m_storage.has<T>(); } T& value() { return m_storage.get<T>(); } bool has_error() const { return m_storage.has<error_code>(); } error_code& error() { return m_storage.get<error_code>(); } bool has_exception() const { return m_storage.has<exception_ptr>(); } exception_ptr& exception() { return m_storage.get<exception_ptr>(); } void set(none_t) { m_storage = none; } void set(const T& val) { m_storage = val; } void set(error_code err) { m_storage = err; } void set(exception_ptr ep) { m_storage = ep; } private: variant<none_t, T, error_code, exception_ptr> m_storage; }; Or this sort of interface: template<typename T> class outcome { public: bool has_value() const { return !!m_value; } T& value() { ensure(); return m_value.value(); } //bool has_error() const { return !!m_error; } const error_code& error() const { return m_error; } //bool has_exception() const { return !!m_exception; } const exception_ptr& exception() const { return m_exception; } void ensure() const { if (m_exception) { rethrow_exception(m_exception); } if (m_error) { throw system_error(m_error); } } void set(none_t) { m_value = none; m_error = error_code(); m_exception = nullptr; } void set(const T& val) { m_value = val; m_error = error_code(); m_exception = nullptr; } void set(error_code err) { m_value = none; m_error = err; m_exception = nullptr; } void set(exception_ptr ep) { m_value = none; m_error = ep ? error_code(errc::has_exception) : error_code(); m_exception = ep; } private: optional<T> m_value; error_code m_error; exception_ptr m_exception; }; (Don't get too hung up on the specifics. This is a sketch, not a real implementation. I've obviously omitted things that a real implementation would need such as more const methods and move support, and construction and assignment rather than using set methods. The focus is on variant vs. non-variant.) Anyway, the point is that this could actually transport multiple things; in particular as above both an error_code and an exception_ptr; perhaps set(error_code) could construct an exception as well, although I've explained elsewhere why I don't like that option. Perhaps this could even be exposed even more so that user code could explicitly provide both a value and an error -- think "here's a value, but it was truncated" or "here's the 5 values you asked for, but there's more", both fairly common in system APIs. Or for things like ambiguous matches where you still return the most likely candidate. Or dictionary insertion (duplicate key, but here's the value that's already there). Or many more such examples. (Though obviously in this case value() couldn't call ensure(). But that should make some people happy.) Also note has_error() and has_exception() don't even need to be provided in this version since you can always call error() and exception() in a boolean context anyway, with the same result. (Or actually a slightly better result than the implementation shown here.) The obvious downside is that it now uses more storage, which might hinder some inlining cases.

9 63

[sort] Timsort review
by Steven Ross 03 Jun '17

03 Jun '17

The review for C++ Timsort in Boost will commence tomorrow, June 3, and continue through June 12. I am the review manager. The code can be found here: https://github.com/boostorg/sort/pull/12 To merge it into a local copy of the Boost.Sort library: git checkout -b ZaMaZaN4iK-feature_branch/TimSort develop git pull https://github.com/ZaMaZaN4iK/sort.git \ feature_branch/TimSort If you want to see a proposed version of the Sort library source with Francisco's changes and Timsort included, download the zip file <https://drive.google.com/file/d/0B4s-GPKYVV0jOGx5ckJUTkZzMWM/view?usp=shari…>. Feel free to compare flat_stable_sort with Timsort. Please answer these questions in reply to this thread: 1. What is your evaluation of the Timsort implementation? 2. What is your evaluation of the comments? 3. Did you try to use the library? With what compiler? Did you have any problems? 4. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 5. How familiar are you with the details of hybrid and stable sorts? 6. Would you actually use Timsort if it was in Boost.Sort? If so, how is it better than the next best alternative? 7. Do you think Timsort should be included in Boost.Sort? Please ask Alexander Zaitsev any questions you have about Timsort for this review before submitting your final review. Thanks, Steven Ross

1 0

[poly_collection][VS 2017] Potential compiler bug
by Joaquin M López Muñoz 02 Jun '17

02 Jun '17

Hi, Boost.PolyCollection tests have started to cycle and I found VS 2017 aka MSVC 14.1 fails at test_algorithm.cpp: http://tinyurl.com/yb4zdkys whereas this test compiles and runs OK with VS 2015 aka MSVC 4.0 (_MSC_FULL_VER = 190023026). I've distilled down the problem to this test case: #include <algorithm> #include <utility> template<typename... Ts> struct all_of { template<typename... Args> auto operator()(Args&&... args)const-> decltype(std::all_of<Ts...>(std::forward<Args>(args)...)) { return std::all_of<Ts...>(std::forward<Args>(args)...); } }; int main() { int x; all_of<> alg; alg(&x,&x,[](int){return true;}); } which works fine with GCC and VS 2015 but fails in webcompiler.cloudapp.net with Compiled with /EHsc /nologo /W4 /c main.cpp main.cpp(9): error C3546: '...': there are no parameter packs available to expand main.cpp(18): note: see reference to class template instantiation 'all_of<>' being compiled (_MSC_FULL_VER = 191125331, which I think is VS 2017.3 or something). This looks like a regression to me. Deleting the ->decltype(...) bit makes the problem go away but I need to stay within C+11. * Can someone (STL?) confirm this is indeed a compiler bug? * Any rewording of the code that might be generally applicable to C++11 so that I don't have to include a specific workaround for VS 2017? Thank you, Joaquín M López Muñoz

2 1

[outcome] Outcome Review Period Closes Today (Fri-02-June)
by charleyb123 . 02 Jun '17

02 Jun '17

Hello Everyone, Today concludes the Outcome library review period (Fri-02-June-2017). Great thanks to all that invested so much time and effort to explore in such a disciplined and professional manner the dark corners of error/exception composition and a paradigm/API/implementation proposed by the Outcome library. Your efforts are truly appreciated. Reviews sent to the public list are the following (PLEASE contact me if I've missed your review): *- Paul Bristow (Tue-23-May) *- Daniz Bahadir (Wed-24-May) *- Robert Ramey (Wed-24-May) *- Peter Dimov (Sun-28-May) *- Emil Dotchevski (Sun-28-May) *- Vicente J. Botet Escriba (Tue-20-May) *- Andrzej Krzemienski (Wed-31-May) *- Gavin Lambert (Wed-31-May) My understanding is that as the review concludes today, further reviews are permitted only until the end-of-day UTC. In addition, many notable discussions and topics raised during the review period will also contribute to a final submission decision and summary report. Preparing this report will take some time. I've accumulated extensive notes, but my intention is to review (re-read) all discussion in the context of the "story-arc" and (in some cases) the shifted opinions of some persons during the course of the review (as topics were clarified and alternatives were explored). I assume other "satellite discussions" will continue (e.g., evolution of std::expected<>, suitability of wide vs. narrow contract in APIs, generalization of variant<>, etc.), which I will endeavor to continue to follow as the Outcome Review summary report is prepared (because these continued discussions may further clarify issues previously raised during the Outcome Review); but no more reviews can be accepted after the review period closes. Thank you all (again) for your (often thankless) contributions to the community, where the personal sacrifice in time and effort (and perhaps stressful emotional investment) is quite obviously extensive in many cases. --charley

2 2

[outcome] where is the monadic style tutorial?
by Mathias Gaunard 02 Jun '17

02 Jun '17

Hi, I just took a quick look at outcome today and I don't really understand what it is doing. I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad. I searched throughout the documentation and didn't find any. Why is there no example of this? More than how the error state is captured and stored or how to capture custom errors, I believe the programming model is what the tutorial should really focus on.

3 4

[outcome] Formal review
by Gavin Lambert 01 Jun '17

01 Jun '17

With the extended review period ending soon (or perhaps slightly overdue, depending on timezone), and given my many posts regarding the library, I feel like I should probably express my thoughts in review form. This is my first formal review and I am not myself a Boost library author (just a user) so please take that into account. - What is your evaluation of the design? A lot of thought has clearly gone into it, though I'm not sure I agree with some of the decisions made. Empty state I'm on the fence about; I can see it's convenient both for optional<T> success return semantics and for not-yet-populated/called pending result semantics, but I'm not sure these are consistently applied as it stands, and they seem at least partly opposed to the "empty state is weird, let's aggressively throw" behaviour in the actual implementation. Simplifying expected<T, E> into result<T> and outcome<T> makes sense, and the design of error_code_extended seems reasonable, including the content and ring buffer history. However I wonder if perhaps some middle ground might be better, where result<T, E> and outcome<T, E> exist but E is constrained to a type with specific characteristics (such as being constructible from error_code and having noexcept move). This might allow for more flexible error payloads. Alternately some way to use a similar error_code_extended-linked-to-ring-buffer system but with a user-defined payload data type. I don't consider this to be a defect or reason to reject the library, though, just something that would be useful if possible. I don't like that result<error_code{,_extended}> is not legal, as this seems like unnecessary asymmetry, though again I don't consider this a rejection reason. - What is your evaluation of the implementation? I have not looked in depth at it. The dual licensing and dual source distribution (preprocessed vs. not) bother me, but that will apparently be addressed in future. I don't like the total duplication of interface methods (get vs. value, error vs. get_error), but this will apparently also be addressed in future. (I am not opposed to having both narrow and wide accessors in the same type, though I prefer that the ones that can cause UB if abused require more typing. I *am* opposed to having multiple names for the exact same behaviour.) I'm not sure why it would be useful to provide const&& overloads of some of the value methods. Usually the only time I've seen these is to explicitly delete that overload. (Unless that is what's actually happening and doxygen is just not showing that correctly.) I like the use of wide contracts by default, such that it is safe to call value(), error(), or exception() without inspecting the underlying type and they will react sensibly (eg. throwing) rather than having UB, although some of the finer points of what a sensible reaction means are still being debated. But I can understand the desire of some people to have the other versions available for specific cases or in environments where static checking is more common. Even so, I hope that the narrow versions will at least BOOST_ASSERT their preconditions. The lack of use of Boost facilities such as Config, Assert, and Core (esp. BOOST_NO_EXCEPTIONS) bothers me more, and I do consider that a rejection reason. Use of StackTrace would be good as well but at this point I don't consider that a defect since it's not quite "in" Boost yet. (Possibly also Exception for boost::throw_exception, though using std::exception_ptr is the correct choice.) There is a critical defect in error_code_extended's backtrace API, which has already been brought to the author's attention and should hopefully be resolved later. - What is your evaluation of the documentation? Generally good, although it seems to spend a lot of time and pages talking about expected<T, E>, and only towards the end adds "but you should probably use outcome<T> instead" as a sort of afterthought, which seems a bit backwards. This is perhaps the correct order in a presentation, but it feels wrong in library documentation somehow. I think it needs to be more up-front about outcome and result (since those are the core types of the library) and recommended usage, and cover the other things as background material afterwards. The documentation refers to "monads" a lot, which is an unfamiliar concept to me. Not sure if this needs more explanation or just rewording. Doxygen's habit of putting hyperlinks that go nowhere in the reference pages is a bit disconcerting as well. - What is your evaluation of the potential usefulness of the library? Direct usefulness to me right now will be limited due to compiler support, but this seems like the sort of thing that would be quite useful in the future, especially to tidy up dual APIs such as those in ASIO. They have a fairly good chance of becoming standard vocabulary types, which of course has also helped drive a lot of the discussion thus far. - Did you try to use the library? With what compiler? Did you have any problems? I have not, as the compilers I use day-to-day are only C++11 or less, not C++14. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Primarily a fairly detailed reading of the documentation, combined with discussion here. - Are you knowledgeable about the problem domain? Mixed. I have experience with exception handling internals in MSVC and regularly work with software in both contexts of using error codes everywhere with exceptions banned, and of allowing exceptions but preferring they never actually be thrown. I also regularly work with both low-latency and fixed-latency environments, in addition to more "normal" software. But other than interaction with ASIO I have not made much use of error_codes to date, or mixing the two environments in the "sea of noexcept" fashion, though I can see the appeal. - Do you think the library should be accepted as a Boost library? Eventually, yes, but currently no (rejection, with encouragement to resubmit). While the author claims that the actual implementation has changed little since initial submission, the changelog in the "review accepted feedback" threads sounds fairly serious, and I'm not sure I like some of its directions (such as separate types for contract variations). Perhaps it will indeed end up being no big deal, but I don't feel like I have a good handle on what the end result will look or behave like so I don't feel comfortable endorsing it until I can get a better look at it. Primarily though I think the Boost integration was done backwards; the library should make use of Boost facilities first (as previously mentioned); if also distributed separately then that separate distribution should have the Boost emulation layer in it, and not the reverse. (To clarify: using std:: facilities is preferred, so using <system_error> is better than using <boost/system/system_error.hpp>, although it would be nice if compatible with the latter without actually depending on it unless requested explicitly. But the main problem is lack of use of Config, Assert, and Core, unless I missed something.)

2 2

[units] Compilation fails on quantity copy-construction
by Pavel Kretov 31 May '17

31 May '17

Hi all! I'm trying to make use of Boost.Units in a simple FDTD simulation program, but found a strange behavior of some kind. Consider the following demonstration example where I try to calculate time step from spatial steps according to the CFL condition [1]: #include <iostream> #include <boost/units/physical_dimensions.hpp> #include <boost/units/systems/si.hpp> #include <boost/units/cmath.hpp> #include <boost/units/io.hpp> int main() { namespace bu = boost::units; namespace si = boost::units::si; using dimless = bu::quantity<si::dimensionless, float>; bu::quantity<si::length, float> dx = 1.0f * si::meter, dy = 1.0f * si::meter; bu::quantity<si::velocity, float> v = 1.0f * si::meter_per_second; bu::quantity<si::time, float> dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); std::cout << dt << std::endl; } The code looks okay to me, but when I try to compile it, I get a scary error message: main.cpp:20:19: error: no match for ‘operator/’ (operand types are ‘float’ and ‘<THE_TERROR_THAT_FLAPS_IN_THE_NIGHT>’) dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ where the second operand type looks like boost::units::multiply_typeof_helper< boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<1l>}, {time_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, float>, boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, double>>::type In the above expression [{}, {}, ...] is a pseudo-code for static head-tail list of boost::units::dim<Unit, Rat> pairs. Note the 'double' type materialized from barely nowhere: the code explicitly defines everything as 'float', it's the 'bu::sqrt' to blame for it to appear. Note that replacing 'bu::sqrt' with 'bu::pow<1, 2>()' does not help. As I didn't feel happy with the above error message, I mutated the code a bit and made it to work with: bu::quantity<si::time, float> dt; dt = dimless(0.5f) / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); I had to both (a) add 'dimless', and (b) separate variable declaration and definition. Doing only (a) didn't help. Mkay, but what if I need to have a const quantity? (I'm a big fan of making everything 'const'!). The only one thing I could do was to roll out my own 'sqrt' and 'pow' functions. Here they are: #include <boost/units/get_system.hpp> #include <boost/units/get_dimension.hpp> #include <boost/units/static_rational.hpp> #include <boost/units/quantity.hpp> #include <boost/units/dimension.hpp> template<typename Unit, int N, int M = 1> using static_power_helper = boost::units::unit< typename boost::units::static_power< typename boost::units::get_dimension<Unit>::type, typename boost::units::static_rational<N, M>::type>::type, typename boost::units::get_system<Unit>::type>; template<int N, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N>, Y> { using std::pow; return decltype(ratpow<N>(x))::from_value(pow(x.value(), N)); } template<int N, int M, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N, M>, Y> { using std::pow; return decltype(ratpow<N, M>(x))::from_value(pow(x.value(), (Y) N / M)); } template<typename Unit, typename Y> auto msqrt(boost::units::quantity<Unit, Y> const &x) -> decltype(ratpow<1, 2>(x)) { return ratpow<1, 2>(x); } Using them I was able to compile the original form of the expression (as seen in the very first listing): bu::quantity<si::time, float> const dt = 0.5f / (v * msqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); The questions: 1. Is it possible to work around the problem without custom 'sqrt'? 2. Is the described behavior intentional, -or- Is there an error in Boost.Units' implementation of 'sqrt'? 3. If the 'boost::unit::sqrt' is fine, is there something wrong with my implementation? ――― Pavel K. [1]: https://en.wikipedia.org/wiki/Courant-Friedrichs-Lewy_condition

2 1

[poly_collection] Questions about merging into Boost
by Joaquin M López Muñoz 31 May '17

31 May '17

Boost.PolyCollection was recently accepted into Boost and I'm planning to integrate it into https://github.com/boostorg/ asap to begin test cycling. I am not sure if the lib will be in a good enough shape for launching with Boost 1.65, though. Questions: 1. The current repository is https://github.com/joaquintides/poly_collection , which has branches master (code) and website (for the online docs). Is the following the right procedure for integration with Boost? a. Rename master to develop (https://gist.github.com/lttlrck/9628955 ) b. Transfer repo to boostorg (https://help.github.com/articles/about-repository-transfers/ ) c. Ask for write permission to github.com/boostorg/poly_collection 2. Can the repo not have a master branch until I decide the lib is ready for launch? Will this result in poly_collection simply not being in Boost releases while still develop tests are cycling? Thank you, Joaquín M López Muñoz

4 4

[outcome] Andrzej's review
by Andrzej Krzemienski 31 May '17

31 May '17

Hi Everyone, This is my review of Boost.Outcome library. First, I want to thank Niall for taking the effort to write the library, promoting it, sharing with the community, and submitting for Boost review. I think that the library has already proven useful regardless of this review's outcome (or should I say 'result'). I recommend to REJECT the library at this point, and encourage the author to re-submit it after the list of what I consider issues -- described below -- has been addressed. Why reject and not conditionally accept? It is possible to say that I accept the library if this "delta" is applied to the current submission's state. Niall has indicated a couple of times that he is willing to apply even big changes, if this is what reviewers wish. But the amount of change that would be required, plus the uncertainty what the "delta" actually is, plus a general confusion as to what library is for, as reported by others (the effect of the current shape of documentation), in total make the conditional acceptance too fragile. What are we reviewing? It would be fair to assume that we are reviewing the master branch, SHA 4851926c1c601c0e9391b2d0d07fb17f634b3ecb, but there is also a "delta" described by Niall in high-level in one of the messages: http://boost.2283326.n4.nabble.com/outcome-High-level-summar y-of-review-feedback-accepted-so-far-td4694767.html. So maybe the master + that delta. It describes that we will have like 10 types, like outcome_e, checked_outcome_e, etc.. Now in another thread I hear there will only be 5 types: optional_outcome and outcome. This makes me believe that the compromise solutions and promises are being made in a hurry, and this will likely result in (1) suboptimal design and (2) misunderstandings as to what we are actually agreeing to. Am I knowledgeable about the problem domain? If the domain is "reporting function failures in predictable-latency environments", then no, I have no experience with this domain. I also have no experience with `expected`, although having worked on formal specification of `std::optional` I am familiar with a number of issues that `expected` also needs to solve. Also, a number of controversies revolves around git sub-modules, dual licensing and Boost distribution process. I do not feel competent in this area either. How much effort did I put into the evaluation? I have read a number of versions of the documentation. Had a long email exchange with Niall in order to understand what the library does. I had a glimpse at the source code to figure out the pieces that were missing from documentation. I have tried running my own test examples on GCC 6.3.0 with MinGW w64 5.0.0 (doesn't work) and GCC 6.3.1 on Fedora (works fine). Is the library useful? Yes. Apparently it solves an important problem in predictable-latency environments. This is confirmed by the user base the library already has managed to acquire. It provides an implementation of the to-be standardized `exceptional`, which allows for experimentation. I believe Boost would benefit from including this library (after the issues have been resolved). I am confident Niall has knowledge about problem domain. Documentation. It has two serious deficiencies. It lacks an introductory part that would clearly and shortly describe what problem the library is solving an how, how can I use it and when should I use it. It is also missing a reference with documented semantics. One cannot tell what outocme's default constructor does, or what function error() does when you have an exception_ptr inside. I believe Niall when he says his users do not need this documentation: they immediately grasp what and how it is doing. But of the Boost library I expect a high-quality documentation. I think that these deficiencies in the documentation prevent a successful review of the library. I bet there are people who were put off by the docs and will not proceed to reviewing the library further, even though they could have given you many valuable insights, or point out defects. Some will stop at criticizing the docs. Any potential flaws in the library will not even be revealed. This may be the reason why things like ring buffer were not opposed: the potential critics may have not gotten that far. This is one of the reasons that I would recommend fixing the docs and staring the review again without the distraction. On the other hand, there is a lot of useful material in the documentation. For sure it is a way better that the original versions. For instance, the usage of ring buffer is documented clearly. Design. The idea to represent either a returned value or a reason for the lack thereof as `variant<T, error_code, exception_ptr>` is sound. Fixing the `E` to a single type is sound. using_error_code extended (along with ring buffer) for carrying payload is sound. I also like the fact that you only have three "monads": `outcome`, `result` and `expected`, and that they are maximally different: expected and result make the opposite decision on practically any aspect. This is a reasonable compromise between many possible combinations of micro-decisions, and the expectation to have a small number of types. `option` should go, I think. I can think of no use case for it. However, the design still changes throughout the review, and has not stabilized yet. The last message is that we may have varieties for narrow versus wide contract or we will have duplicated observers, and this has not been settled on yet. The consequence of using the ring buffer, where the error message can suddenly disappear is unfortunate, but then again, I know of no way to make it better. It might be the best choice of those available. I wish someone from low-latency users stepped in and commented on whether this is the right choice and whether the choice of these particular members (a short string, two unsigned ints) is the optimum in practice. Some aspects of design, to me seem unclear. E.g., what does it mean that `outcome` has value but I am calling `o.error()`? Is it a programmer error, which the function is trying to conceal, or does `o.error()` mean "convert `outcome` to `error_code`, whatever the state? Similarly, when `exception()` also recognizes error_codes, and `error()` does not recognize exception_ptrs looks quite random: I cannot see a mental model behind it. You could document detailed semantics of each function, but this would not be enough. I need a clear mental model, like "every error_code or exception_ptr is collectively called 'exception' in this library". If you do not support `outcome<T&>, I need a clear indication of it and a rationale. Implementation. These dual licensing, testing and git sub-module issues. I am not an expert in how Boost is organized, but a number of people I consider qualified have reported strong objections, and this has to be considered. A Boost library must be compliant with "the way things work in Boost" even if it is felt that things work wrong in Boost. I did not look much, at the implementation, but it looks acceptable on the surface. The assignment (most tricky part, I think) is implemented quite clearly. Sometimes static_assert's constrain too much. A non-default-constructible types should be allowed. Types that throw upon copy/move construction should be allowed provided I do not call the assignment on outcome/expected. I am told `outcome<error_code>` does not work. I am not sure if this is fortunate. It is no longer an `outcome<T>` that works for any Regular T. What if I have a function that optains an error_code and might potentially fail. How can I express this in the interface? (Or do I have to wrap in `outcome<unique<error_code>>`?) `outcome` has function swap overloaded in namespace std. I am not sure if it is legal, but even if so, I would recommend implementing it in `outcome`'s namespace, in order not to mess with `std`. Again, thanks Niall for this library, and for a very educational discussion. Regards, &rzej;

2 1

[units] Compilation fails on quantity copy-construction
by Pavel Kretov 31 May '17

31 May '17

Hi all! I'm trying to make use of Boost.Units in a simple FDTD simulation program, but found a strange behavior of some kind. Consider the following demonstration example where I try to calculate time step from spatial steps according to the CFL condition [1]: #include <iostream> #include <boost/units/physical_dimensions.hpp> #include <boost/units/systems/si.hpp> #include <boost/units/cmath.hpp> #include <boost/units/io.hpp> int main() { namespace bu = boost::units; namespace si = boost::units::si; using dimless = bu::quantity<si::dimensionless, float>; bu::quantity<si::length, float> dx = 1.0f * si::meter, dy = 1.0f * si::meter; bu::quantity<si::velocity, float> v = 1.0f * si::meter_per_second; bu::quantity<si::time, float> dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); std::cout << dt << std::endl; } The code looks okay to me, but when I try to compile it, I get a scary error message: main.cpp:20:19: error: no match for ‘operator/’ (operand types are ‘float’ and ‘<THE_TERROR_THAT_FLAPS_IN_THE_NIGHT>’) dt = 0.5f / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ where the second operand type looks like boost::units::multiply_typeof_helper< boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<1l>}, {time_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, float>, boost::units::quantity< boost::units::unit< [{length_base_dimension, static_rational<-1l, 1l>}], boost::units::si::system, double>>::type In the above expression [{}, {}, ...] is a pseudo-code for static head-tail list of boost::units::dim<Unit, Rat> pairs. Note the 'double' type materialized from barely nowhere: the code explicitly defines everything as 'float', it's the 'bu::sqrt' to blame for it to appear. Note that replacing 'bu::sqrt' with 'bu::pow<1, 2>()' does not help. As I didn't feel happy with the above error message, I mutated the code a bit and made it to work with: bu::quantity<si::time, float> dt; dt = dimless(0.5f) / (v * bu::sqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); I had to both (a) add 'dimless', and (b) separate variable declaration and definition. Doing only (a) didn't help. Mkay, but what if I need to have a const quantity? (I'm a big fan of making everything 'const'!). The only one thing I could do was to roll out my own 'sqrt' and 'pow' functions. Here they are: #include <boost/units/get_system.hpp> #include <boost/units/get_dimension.hpp> #include <boost/units/static_rational.hpp> #include <boost/units/quantity.hpp> #include <boost/units/dimension.hpp> template<typename Unit, int N, int M = 1> using static_power_helper = boost::units::unit< typename boost::units::static_power< typename boost::units::get_dimension<Unit>::type, typename boost::units::static_rational<N, M>::type>::type, typename boost::units::get_system<Unit>::type>; template<int N, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N>, Y> { using std::pow; return decltype(ratpow<N>(x))::from_value(pow(x.value(), N)); } template<int N, int M, typename Unit, typename Y> auto ratpow(boost::units::quantity<Unit, Y> const &x) -> boost::units::quantity<static_power_helper<Unit, N, M>, Y> { using std::pow; return decltype(ratpow<N, M>(x))::from_value(pow(x.value(), (Y) N / M)); } template<typename Unit, typename Y> auto msqrt(boost::units::quantity<Unit, Y> const &x) -> decltype(ratpow<1, 2>(x)) { return ratpow<1, 2>(x); } Using them I was able to compile the original form of the expression (as seen in the very first listing): bu::quantity<si::time, float> const dt = 0.5f / (v * msqrt(1.0f/(dx*dx) + 1.0f/(dy*dy))); The questions: 1. Is it possible to work around the problem without custom 'sqrt'? 2. Is the described behavior intentional, -or- Is there an error in Boost.Units' implementation of 'sqrt'? 3. If the 'boost::unit::sqrt' is fine, is there something wrong with my implementation? ――― Pavel K. [1]: https://en.wikipedia.org/wiki/Courant-Friedrichs-Lewy_condition

1 0

[config] C++17 macros wanted
by Tal Lancaster 31 May '17

31 May '17

I have been adding C++17 features to date_time. There are two config macros, I would like to have: Test for C++17’s constexpr inline feature. Maybe call it something like: BOOST_NO_CXX17_CONSTEXPR_INLINE Test for C++17’s structured binding feature. Maybe call it something like: BOOST_NO_CXX17_STRUCT_BIND

3 7

[outcome] How to drop the formal empty state
by Niall Douglas 31 May '17

31 May '17

There has been a fair bit of review feedback that people don't like the formal empty state in outcome<T> and result<T>. I still think this opinion daft, just because it's there doesn't mean you have to use it, but here are some options: 1. Like Expected, we could require the E types to provide a nothrow move constructor. This would allow us to guarantee no empty state, not ever. Default constructing an outcome<T> or result<T> would set a default constructed T state, just like Expected. The only remaining difference now between result<T> and expected<T> would be the wide vs narrow observer functions. outcome<T> still can also carry a std::exception_ptr. 2. We could do the above, but default constructor constructs to some constexpr undefined state that is not state T nor E. 3. We could only provide a guarantee of no empty state if the E types provide nothrow move construction, but if they do not we fall back to an empty state arising if throws occur during assignment. 4. The option for an empty state becomes a template parameter defaulted to false i.e. disabled. This can be combined with any of the above. Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 47

[review] Review of Outcome (ends Fri-June-2)
by charleyb123 . 31 May '17

31 May '17

Reminder -- On Fri-26-May the Review Wizards approved extending the Outcome review until Fri-02-June. (Notification was sent to the list, but considering the high traffic volume lately, one can be forgiven for having missed that message.) Thank you to everyone for your tremendous efforts in taking part in the review; for keeping up with high message traffic; and for the professional and deep exploration of the many (very broad!) topics touched on during this review. The review continues for several more days, ending Fri-02-June (it will not be extended further). Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

3 2

[gil] where is the mysterious boost::gil::read_image function?
by Frédéric Bron 31 May '17

31 May '17

I would like to read a jpeg image from a memory location, not from a file. According to this post http://boost.2283326.n4.nabble.com/gil-io-new-review-Reading-images-from-in… there is a boost::gil::read_image(input_stream, image, image_tag) function but I cannot find it in the header files. Thanks, Frédéric

1 0

[future.then] Should deferred continuation respect status of original future?
by Tomas Sturm 31 May '17

31 May '17

Hi, consider this code that wraps some library returning a future: // some async library boost::future<intermediate> DoLongAsyncTask() { return myPromise.get_future(); } // intermediate translation layer boost::future<result> GetResult() { return DoLongAsyncTask().then([] (boost::future<intermediate> f) { return TranslateToResult(f.get()); }); } // client event loop void RunInClientContext() { auto myFuture = GetResult(); while (stuffToDo()) { doStuff(); if (SafeToCallFutureGetWithoutBlocking(myFuture)) ProcessResult(myFuture.get()); } } What should the implementation of 'SafeToCallFutureGetWithoutBlocking' be? Normally, one would write something like: myFuture.is_ready() or myFuture.wait_for(chrono::seconds(0)) != future_status::timeout But this doesn't work in case the implementation of intermediate translation layer calls .then with launch::deferred! In Boost 1.63 the future returned from .then(launch::deferred, ...) is always deferred, so wait_for(...) always returns deferred no matter what (and is_ready() always returns false). In fact, there is no way to implement 'SafeToCallFutureGetWithoutBlocking' if the translation is to happen in the context of the client (launch::deferred). Wouldn't it be more natural to respect the status of the original future in this case? The documentation is already very clear that the continuation is executed only after the original future is ready. So in case a client asks whether the continuation future is ready, and the original future is not ready yet, the call should forward to the original future instead. What I propose is this: promise<int> p; future<int> f1 = p.get_future(); future<int> f2 = f1.then(launch::deferred, [] (auto f) { return f.get(); }); assert(f2.wait_for(0) == future_status::timeout); p.set_value(42); assert(f2.wait_for(0) == future_status::deferred); Is there any reason for the continuation future to not behave this way? Regards Tomas

2 1

[outcome] narrow-contract, wide-contract, and value_if
by Andrzej Krzemienski 31 May '17

31 May '17

Hi Everyone, Some comments about `outcome`'s observers with narrow and wide contracts. First, the wide-contract functions. We have a situation when someone assumes that `o` currently stores an error_code, and with this assumption in mind calls `o.error()`, but somehow his assumption is incorrect. What do we want to do? 1. Try to report programmer's bug at run-time? 2. Since in this case it is a bug anyway and are screwed, at least let's make such behavior useful for other situations where `error()` is called conciously on `o` without an error code? The first scenario attempts at identifying a bug, bringing it to attention of developers (maybe in form of a log), and minimizing its consequences by perhaps skipping the execution of some part of the program in hope that the bug will no show symptoms again. The second scenario in a way ignores the bug, and lets the program continue, as though it was correct, and from now on the program is doing something else than what the programmer intended. But the semantics of the function are useful in itself. Users who check `o.has_error()` before calling it can use it as if `error()` had a single purpose and a narrow contract; and users who know the additional semantics can use it for other useful things, like saving themselves of writing some boilerplate code. It is my impression that some of these observer functions in `outcome` follow this second scenario: just do something useful for people who use it unchecked. Saving boilerplate is useful, but let's state it clear: these functions offer no protection against inadvertent mistakes: no run-time or static protection. If I call `o.error()` and it throws when `o.is_empty()`, it is a form of protection. If `o.error()` returns `E{}` when `o.has_value()`, this is no protection, it is convinience function that can be used as a narrow-contract observer. Maybe the interface of `outcome` should make this distinction and offer two sets: one for observers with run-time protection, and the other for nice convenience functions? Second, narrow-contract functions. Narrow functions acheive the following goals: 1. Simple design: function only does one thing, it does not have any if inside. 2. The interface of the library makes a clear distinction of what is valid and what is an invalid usage of the library. It helps in code reviews. For instance, you are looking for a bug in a big code, you find the following piece: ``` auto e = o.error(); ``` and it turns out that `e` contains a value. Did you just find a bug, or was it the author's intention to get an `E{}` at this point? You do not know with wide contracts. With narrow contracts you know: it is a bug. 3. Narrow contracts assist instrumentation in test builds and runs. If I have function `just_value` with a narrow contract, I leave myself the freedom: I can do whatever I want when has_value() is false. What can I do with this freedom: A. In test build, I can check the precondition at run-time and launch the debugger B. I can (run-time) check the precondition, and std::termiante() or throw an exception. C. I can ignore the potential precondition violation, check nothing and aim at some performance gain. D. I can put some code that assists the static analyser (like __builtin_unreachable()) E. I can put some instrumentation code that assists an UB sanitizer (like __builtin_unreachable()) F. I can put hints for optimizer (like __builtin_unreachable(), again) G. Finally, I can put a macro `PRECONDITION(has_value())` which can do any of the above based on the build configuration. Given that, the proposed function `value_if` (which returns a pointer to value) will not satisfy my needs. It has a wide contract, so I cannot put macro `PRECONDITION()` inside. It rturns a pointer. The pointer's operator-> inded does have a narrow contract, but it gives me no room where I can put macro `PRECONDITION()`. So I get some narrow contract, but without the benefits I am looking for. So that is my view of the observer functions. Now my proposal is to provide a pair of observers for each value, error_code and exception -- narrow and wide: `value()` and `just_value()`, `error()` and `just_error()`, `exception()` and `just_exception()` Or maybe, even three for narrow-contract, wide-contract with run-time protection, and for convenience function: `error()` -- wide-contract, runtime-checked precondition `just_error()` -- narrow contract `as_error()` -- convenience function, e.g. returns E{}, on value, monad::has_exception on exception, etc.. Regards, &rzej;

2 2

[outcome] user's experience
by Andrzej Krzemienski 30 May '17

30 May '17

Hi Everyone, In order to test Boost.Outcome, I applied it to the problem I had to solve at work a while ago. For people who do not know what Boost.Outcome is for, this could be an introduction. For me it can be an opportunity to obtain feedback from Niall and Vicente, If I am using `expected` correctly, and they can get some feedback from me. Here is the task. I get an std::string as input: it is a data structure encoded in ASCII text: "1-10|11-20|21-99;1-10|10-50|51-99" Semicolons separate "distributions". Within distribution, vertical bars separate "ranges". Within ranges, dashes separarate integer numbers. There are some additional constrains. like ranges within distribution cannot overlap, no gaps between ranges are allowed, and a couple more. I need to validate if the input matches the required format, and build a corresponding data structure. But the vaidation cannot be just binary valid-invalied answer: I want to give user a description of what exactly is wrong with her input, as detailed as possible. So, I have function parse, that internally calls parse_distribution, which in turn calls parse_range. Each of them can return different parsing error that needs to be propagated up. My original implementation used "out" function parameters for signalling errors. Code was unnecessarily long and it was easy to forget to check results from functions, but I didn't want to use exceptions to indicate validation failures, because there is nothin exceptional about it. You expect input validation to fail -- quite often. Now, this is a more philosophic question: when to use (or not) exceptions. One citerion I sometimes use is, "do I want my debugger to automatically break if this function reports faiure?" So I didn't use exceptions for input validation, but the ugliness of the code forced me to go back to rewrite it with exceptions. The code was shorter, and "saer" in the sense that I could not forget ot pass the failure up the stack. Now with Boost.Outcome I have a third option. It is almost as concise as exceptions, but does not use exceptions. Here is my implementation: https://github.com/akrzemi1/__sandbox__/blob/master/outcome_practical_examp… Note a couple of things. I am creating a number of temporay strings under way, they all can throw bad_alloc. I am fine with that. I am not affraid of throwing an exception, it is only the validation failures that I want to report with `expected`. For other failures I want exceptions. This is input validation. It does not have to be super fast. In the public API of this file, I will not be exposing the information about parsing failues. `process` will consume the error information and just output something. So, the choice of `E` in `expected<T, E>` is internal to a file, and I can choose something specific to my use case. I provid my own type, which encodes different erroneous situations in an enum, and two ints for additional details. ``` struct BadInput { enum { no_distrib = 1, range_count_not_3, distrib_starts_with_no_1, distrib_ends_with_no_99, gap_between_ranges, overlap_between_ranges, inverted_range, no_2_numbers_in_range, not_a_number, } type; int val1; int val2; }; ``` It is quite similar to Outcome's error_code_extended. Now, I also wanted to have an std::string member inside, but `expected` forbids it: It says as per LWG requirements `E` in `expected<T, E>` must not kave a throwing copy constructor. Is that right? In my use case it wouldn't harm anyone: if copying of `expected` throws, entire function `process` is exited, with a bad_alloc, which is fine. No `expected` with partial state will be ever observed. Do we need this restriction? Also, at some point I will be returning an `expected<vector<T>, E>`, which makes me uneasy. Returning vectors wrapped in something: will I get runtime penalty for it? So, I naturally arrived at a pattern that Niall described in the other thread: ``` out::expected<vector<T>, E> parse (...) { out::expected<vector<T>, E> ans {out::value}; vector<T> & vec = ans.value(); // will if statement be ellided?} // fill vec return ans; } ``` (BTW, this constant out::value is not documented in the docs, unlike out::value_t.) It has been mentioned a number of times that an optimizing compiler can remove a redundant if-statement. I know that the if-statement inside `value()` is redundant, but in this particular case, will compiler know it to? Nobody has called `has_value()` before. Also, the following piece of code illustrates how concise the implementation of a single function can be: ``` // I use a shortet alias for macro BOOST_OUTCOME_TRYX. // It is not portable, though. It only works on Clang and GCC. #define TRY(ex) BOOST_OUTCOME_TRYX(ex) out::expected<Range, BadInput> parse_range (const std::string& input) { tokenizer numbers_s {input, sep_3}; auto it = numbers_s.begin(), itEnd = numbers_s.end(); int count = std::distance(it, itEnd); if (count != 2) return out::make_unexpected(BadInput{BadInput::no_2_numbers_in_range, count}); Range r {TRY(parse_int(*it++)), TRY(parse_int(*it++))}; if (r.lo > r.hi) return out::make_unexpected(BadInput{BadInput::inverted_range, r.lo, r.hi}); return r; } ``` It is almost as short as if I used exceptions, except for the TRY macro. Note in particular this line: ``` Range r {TRY(parse_int(*it++)), TRY(parse_int(*it++))}; ``` `parse_int()` returns `out::expected<int, BadInput>`.Now, `TRY(parse_int(...))` is an expression and means, "if parse_int() failed immedaitely return function `parse_range` with the same BadInput, otherwise use its `value()` to initialize `r`. What do you think. Am I using the library correctly? Regards, &rzej;

4 7

[outcome] Exception safety guarantees
by Andrzej Krzemienski 30 May '17

30 May '17

Hi All, This is in connection with Vicente's question: what exception safety should we expect of copy assignment of `expected`? Now, this is really funny because we are talking about exception safety in something that is used as a substitute for exceptions. That is, one of the use cases for `expected` is to be able to get rid of exception handling altogether (while still reporting failures). But this fundamental problem, "what state my object is in if this mutating operation fails" is not specific to exceptions. It is speciffic to operations that might fail; and how (and if) they signal failures is of secondary importance. So, let's talk about *failure safety* rather than 'exception safety'. First, let's consider the use case for `expected`, where we want to disable exception handling altogether. This means `T` or `E` cannot throw on any operation. But copy assignment can still fail, right? Or maybe in these domains you are only using trivially-copyable types as `T` and `E`. Or maybe in these domains you never have a need to copy-assign instances of `expected`? Is so, they provide a *no-fail* guarantee, and any implementation of `expected` will be good and offer no-fail guarantee also. Bus if some copying operation on T or E can fail, how is the failure reported? Through a return value? Output parameter? But whatever the answer, we are arriving at the "nested failure" problem: we are processing a (potential) failure report, and this processing fails. What should we do? report the new error condition and ignore the previous? This is very close to a double-exception during stack unwinding. In C++ it std::terminates, other languages ignore the original error, or build a combined error report. All these solutions not satisfactory, and maybe no satisfactory solution exists. I would like to hear an opinion from people who deal with `expected` in exception-disabled environments. On the other extreme, you fave my example with parsing input (which Vicente observed is not parsing, but matching): https://github.com/akrzemi1/__sandbox__/blob/master/outcome_practical_examp… In that case, If I get an exception anywhere (not only upon copying T or E) I want stack to be unwound so far, that all not `expected` objects will remain. So I only care about basic failure guarantee: just let me correctly destroy these objects. In the middle: you have the situation where you copy-assign an `expected` and a copy-constructor of assignment of T or E throws. But where did this exception come from, given that you are using `excepted` for signalling failures? Or are you signalling some failures with exceptions and some with `expected`? And if so, are exceptions not more panic-like? And in that case yu would like to abandon the processing of any `expected`? Anyway, the most difficulties stem from the case where you are storing an E in `expected` and you want to assign an `expected` storing T. You have to first destroy E, and then may not be able to construct a T. My solution to this would be to go to the advice from the first days of forming exception safety guarantees: provide basic guarantee by default, and strong guarantee only if it does not cost too much. We are used to STL containers providing strong assignment, but this is because they are pointers, and they can implement it for free. But does std::touple provide a strong guarantee? No. Do aggregate types provide stron guarantee? No. And can it result in inconsistent data? It can: ``` struct Man { std::string fist_name, last_name; }; Man m1 = {"April", "Jones"}; Man m2 = {"Theresa", "May"}; try { m2 = m1; } catch(...) { } ``` `m2` may end up being {"April", "May"}. And we are taught to write types like this. But if this hapens, the blame is on whoever allowed these objects to outlive the "stack unwinding bubble". So my view, as of today, is not to strive for a strong or even never-empty guarantee. Provide a conditional guarantee, if types T and E don't throw, you get no-fail guarantee. If they do, you only have a basic guarantee: you can destroy, assign to, or maybe call valueless_by_exception(). Nothing more. I think `std::variant` made the optimal choice. And people should code so that instances of `expected` (at least those with T or E throwing on copy/move) should not outlive the "stack unwinding bubbles". Also, note what vector::push_back does when T is non-opyable and its move constructor is potentially throwing: if T's move throws upon reallocation, the behavior is undefined. Regards, &rzej;

8 42

[outcome] Review of Outcome
by Peter Dimov 30 May '17

30 May '17

What follows is my review of the Outcome library. I. DESIGN --------- The general idea of an error handling framework is sound, extremely appealing, and I found it well explained in the documentation. I like the concept very much and agree with many of the design decisions taken throughout. Specifically, constraining the error type to be the fixed std::error_code (or equivalent) and providing a wide accessor interface. I don't think that option<T> should have been included at all. It duplicates optional<T> and has no good reason to exist other than to showcase that the underlying policy-based implementation can produce it. I don't consider expected<T, E> a particularly needed part of the library; the focus should be on result<T> and outcome<T>, the two classes that represent the error handling philosophy on which the library is built. As already stated, I consider the interface of result<T> and outcome<T> a bit too cluttered. Not everyone shares my design preferences for minimal but complete interfaces, so there's legitimate argument to be had over whether, for instance, operator*, operator-> or value_or ought to be included, but the needless duplication between get() and value() is, well, needless. For an initial submission, it's better to err on the side of too little, rather than too much, because it's easy to add later, hard to remove. The empty state has been a source of controversy, and with reason. My initial stance was that it simply needs to go. This however presents a legitimate design question as to what the behavior of the default constructor ought to be. After seeing the suggestions of leaving the object uninitialized there, I now see the empty state as a significantly lesser evil. Having an empty state without the default constructor putting the object into it however is pointless. I do not agree with the direction things have taken of providing a multitude of result classes instead of a single one. Components that are intended to be used in interfaces should provide one, carefully designed option, which encourages what the designer deems best practices. The idea here, assuming that we shoot for standard acceptance at some point, is to provide std::result<T> and have APIs return it, not provide a bag of options and let everyone pick its own thing. (They already do that today and we're not better for it.) I do not agree with making value() unchecked by default. As I explained, one expression of the error handling philosophy behind the library is the following snippet: auto r = function().value(); where function() is noexcept and returns result<T>, whereas the place where the above line appears is a higher level component that signals errors not via error_code, but via exceptions. This one-liner provides the transition in an elegant way; losing it obscures the vision behind the library. Instead of using std::error_code, the library provides its own error_code_extended, complete with an interesting and very useful ring buffer logging mechanism that stores additional information along with the standard code/category values. Specifically, it returns error_code_extended from result<T>::error(). I would separate things a bit further here, attaching the additional information not to a separate error_code_extended class, but to result<> itself. That is, result<>::error() would return std::error_code, and I'd provide a separate accessor, result<>::error_info(), say, that would return the ring buffer entry associated with this result<>. This for me provides a cleaner separation between the basic result<> functionality, and the extended one, although this is a matter of taste. I would also support chaining result<>s by storing the index of the parent ring buffer entry in the current ring buffer entry. This is a straightforward and very useful extension. Instead of providing a macro BOOST_OUTCOME_CATCH_EXCEPTION_TO_RESULT, I would provide result<T>::set_error_from_exception(std::exception const& e); and outcome<T>::set_error_from_exception(std::exception const& e, std::exception_ptr const & p); that would do more or less what the macro does, except the fallback in the second case would be to store p instead of (EINVAL, e.what()). I'd also use make_error_result and make_value_result instead of make_errored_result and make_valued_result, as the former seem more grammatically correct. II. IMPLEMENTATION ------------------ The implementation, from a cursory look, appears of high quality, which is not surprising given that it was in use for two years. The preprocessed header is not easy to review, but the non-preprocessed form is available and amenable to study. Simple examples using outcome<T> compile and work well, although under VS2017 Clang/C2 windows.h is included, which is unfortunate but fixable. The library does not provide a test/Jamfile, which means that as submitted it will not integrate into Boost's testing infrastructure. Given that a Jamfile that performs the equivalent of withmsvc.bat is trivial to write: import testing ; project : requirements <include>../include/boost/outcome/v1.0 ; run unittests.cpp ; the omission is inexplicable. (Further integration into the Boost test matrix would ideally entail splitting unittests.cpp into separate .cpp tests so that success/failure can be tracked independently.) With the above Jamfile, trying to test the library with Cygwin gcc fails with: D:\tmp2\boost-master\libs\outcome\test>b2 toolset=gcc-cxx14 [...] gcc.compile.c++ ..\..\..\bin.v2\libs\outcome\test\unittests.test\gcc-cxx14-6.3.0\debug\unittests.o In file included from ../include/boost/outcome/outcome.hpp:26:0, from unittests.cpp:34: ../include/boost/outcome/outcome_v1.0.hpp:1446:22: fatal error: execinfo.h: No such file or directory #include <execinfo.h> ^ compilation terminated. I realize that Cygwin is not a supported platform, but this is what I have here and this is what I test with, so I figured I'll give it a try. Trying to test with VS 2017 fails with: D:\tmp2\boost-master\libs\outcome\test>b2 toolset=msvc-14.1 [...] compile-c-c++ ..\..\..\bin.v2\libs\outcome\test\unittests.test\msvc-14.1\debug\threading-multi\unittests.obj unittests.cpp unittests.cpp(780): error C3245: 'boost::outcome::_1_0_std_std_9274c0d4::basic_monad<boost::outcome::_1_0_std_std_9274c0d4::policy::monad_policy<udt>>::is_constructible': use of a variable template requires template argument list d:\tmp2\boost-master\libs\outcome\include\boost\outcome\outcome_v1.0.hpp(4271): note: see declaration of 'boost::outcome::_1_0_std_std_9274c0d4::basic_monad<boost::outcome::_1_0_std_std_9274c0d4::policy::monad_policy<udt>>::is_constructible' unittests.cpp(780): fatal error C1903: unable to recover from previous error(s); stopping compilation I get the same failure with /std:c++latest. Testing with the msvc-14.0 toolset works. The library as submitted contains both a preprocessed, fully self-contained, single header named outcome_v1_0.hpp, which is used by default, and a traditional non-preprocessed form that can be chosen with a macro. For the non-preprocessed form to be functional, a git submodule is incorporated by reference: [submodule "include/boost/outcome/boost-lite"] path = include/boost/outcome/boost-lite url = https://github.com/ned14/boost-lite.git branch = master fetchRecurseSubmodules = true ignore = untracked which in turn incorporates two more submodules: [submodule "include/gsl-lite"] path = include/gsl-lite url = https://github.com/martinmoene/gsl-lite.git branch = master fetchRecurseSubmodules = true ignore = untracked [submodule "pcpp"] path = pcpp url = https://github.com/ned14/pcpp.git branch = master fetchRecurseSubmodules = true ignore = untracked The first of these is not by the library author, and the second is a derived work. It is not possible for a Boost release, say, boost_1_65_0.zip, to incorporate git submodules by reference, so there remains a question of what, exactly, is being submitted for inclusion. My attempts to clarify this with the author have proven unsuccessful. I consider this a critical defect of the submission. It is simply not possible for a reviewer to give an opinion whether the submission ought to be included into Boost releases without it being known what, specifically, is being proposed to be included. There is no problem with the library containing implementation details under its directory, but we need to know what these details are. What the library actually needs as dependencies from boost-lite is not much and it's perfectly possible to extract the necessary parts and prepare a self-contained submission. This should have been done prior to the review. The files in the library contain the following: ``` Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License in the accompanying file Licence.txt or at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Distributed under the Boost Software License, Version 1.0. (See accompanying file Licence.txt or copy at http://www.boost.org/LICENSE_1_0.txt) ``` This intends to dual license the library, but as written, it doesn't. What it does is apply the terms of BOTH licenses to distribution and use. This is also a critical defect. If the library is included in a Boost release, it should make it perfectly clear that it's licensed under the Boost license, and not under the intersection of Boost and Apache 2.0. There are several ways to do it, one is to clarify the above to specifically say "ASL2 or BSL, at your option" in the appropriate legalese, another is to license the Boost-included Outcome under BSL and the standalone Outcome under whatever. My recommendation would be to just license the lot under BSL and be done with it. Dual licensing creates unnecessary legal complications and may, from a legal point of view, be more burdensome than just using the BSL. Contributors need to be aware that they are licensing their patches under both licenses, it might not be very clear whether they have been aware, and so on. At times, the library duplicates certain functionality present elsewhere in Boost. I do not consider this a defect. It's a legitimate design decision to avoid intra-Boost dependencies, although the author needs to be aware of the downsides - using Boost components is basically taking advantage of free work instead of having to maintain everything oneself. III. DOCUMENTATION ------------------ I found the documentation perfectly adequate and was able to get a very good outline of how the classes were designed, how they were intended to be used, and what problem they intend to solve. It focuses a bit too much on expected<T, E>, which is not in itself a bad thing but is, for me, not exactly what the library is about. Fixing E to std::error_code is a fundamental (and correct) design decision from which these classes derive much of their utility. The Doxygen-generated reference will not win any awards, but it does the job. It however contains too many implementation details that would ideally either not be there at all, or tucked away in their own separate section. The monadic content is also a bit too high for my taste, and I would prefer if a user of result<> and outcome<> does not encounter the word monad at all. IV. VERDICT ----------- Should Outcome be accepted? In short, eventually. This, at present, is a NO. Ideally, what I would like to see is the library resubmitted in a conventional form, consisting of exactly the files that are intended to go into the libs/outcome directory in boost_1_65_0.zip, licensed under the BSL, only containing the files necessary for the non-preprocessed version of the code to compile and work. In addition, the test/ subdirectory would contain a Jamfile that is ready to integrate into the Boost test matrix.

4 14

[build] conditional run of unit-tests?
by Oliver Kowalke 30 May '17

30 May '17

In the unit tests I want conditionally run some unit-tests - depending on property <target-os>- On Windows systems the unit-test should apply/build with property <context- impl>winfib and on POSIX (non-Windows) <context-impl>ucontext. The Jamfile below doesn't work (Windows version build on POSIX) - xould I get a hint how to fix it (couldn't find a reference of rule 'run'). Oliver [ run test_callcc.cpp : : : <context-impl>fcontext [ requires cxx11_auto_declarations cxx11_constexpr cxx11_defaulted_functions cxx11_final cxx11_hdr_thread cxx11_hdr_tuple cxx11_lambdas cxx11_noexcept cxx11_nullptr cxx11_rvalue_references cxx11_template_aliases cxx11_thread_local cxx11_variadic_templates ] : test_callcc_fcontext ] [ run test_callcc.cpp : : : <context-impl>ucontext [ requires cxx11_auto_declarations cxx11_constexpr cxx11_defaulted_functions cxx11_final cxx11_hdr_thread cxx11_hdr_tuple cxx11_lambdas cxx11_noexcept cxx11_nullptr cxx11_rvalue_references cxx11_template_aliases cxx11_thread_local cxx11_variadic_templates ] : test_callcc_ucontext ] [ run test_callcc.cpp : : : <context-impl>winfib [ requires cxx11_auto_declarations cxx11_constexpr cxx11_defaulted_functions cxx11_final cxx11_hdr_thread cxx11_hdr_tuple cxx11_lambdas cxx11_noexcept cxx11_nullptr cxx11_rvalue_references cxx11_template_aliases cxx11_thread_local cxx11_variadic_templates ] : test_callcc_winfib : <target-os>windows ] ;

2 2

Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
by Vicente J. Botet Escriba 30 May '17

30 May '17

Hi, I believe that this private mail I sent to Niall could concern the Boost community and the Outcome review. While the post concerns the proposed std::experimental::expected, this is applicable as well to Outcome. I've added a more points at the end and some additional information about possible open points for std expected. Le 24/05/2017 à 01:04, Vicente J. Botet Escriba a écrit : > > Hi, > > > After better understanding of the goals of Boost.Outcome I would like > to share two possible extension of std::experimental::expected > > > 1. Implicit conversion when the errors are convertible and the type is > the same. > > I believe this is a missing constructor. > > EXPLICIT expected<T, E>::expected(expected<T, G>); // E is > convertible from G > > I see that the other constructor is also useful > > EXPLICIT expected<T, E>::expected(expected<U, E>); // T is > convertible from U > > and so > > EXPLICIT expected<T, E>::expected(expected<U, G>); // T is > convertible from U and E is convertible from G > > We could as well have an adapt function that transforms expected error explicitly to do error propagation adapt : (E->G) x expected<T,E> -> expected<T,G> (E->G) stands for a function that takes an E and return a G. > 2. variadic expected<Y, E1, ..., En> > > I suggested this already in revision 2 of the Expected standard proposal. > > expected<Y, E1, ..., En> should be something like variant<Y, E1, ..., > En> but with some syntactic sugar. > > > expected<T, E1, ...., En> could be EXPLICIT convertible from > expected<T, G1, ...., Gm> as far as for all Gj we find a unique Ek > that is convertible to. > We can refine the subsumption relation this could take too long to the compiler (as the previous relation has quadratic complexity as Andrzej reported to me). > > I believe this will cover exactly what outcome covers and in addition > it will let open the error types used by the user. > > It acts as a exception specification, which we have abandoned in C++11. > > expected<T, E1, ...., En> f(); > > T f() throw (E1, ...., En); > > > We can consider that this is bad, as we have abandoned it. > > Anyway, I think that expected<T, E1, ...., En> is a good > generalization of the proposed outcome<T> where E1 could be none_t, E2 > could be error_code and E3 is exception_ptr. > > At the end users could use variant<E, E1, ..., En> are return code, so maybe we could to make their life easier. > > In this way we could have > > template <class T> > > using option = expected<T, nullopt_t>; > > Note that this is different to std::optional as the default is T not > nullopt_t :( > I'm not proposing it. Just to say that this could be a possibility for option. > > template <class T> > > using result = expected<T, error_code_extended>; // and possibly none. > > template <class T> > > using outcome = expected<T, none_t, error_code_extended, exception_ptr>; > > > I believe we would need the syntactic sugar as expected<T, > variant<E1,... En>> should have a lot of user code noise. > In addition it will be less efficient than variant<T, E1,... En>. > > E.g. expected<T, variant<E1,... En>> should be convertible from > unexpected_type<G> as soon a one of the Ek is convertible from G. > > I believe variant<E1,... En> is not convertible from variant<G1,... > Gm> under the conditions described above, but maybe this should be the > case. > Andrzej told to me that this is already the case for optional<T>, but I've not found yet on which paper this was added? > > Of course, the never empty warranties could be supported only if the > types Ek allow it and we need to change the standard to ensure it for > exception_ptr. > > > I will not have time to implement a POC for 2, but I believe I could > do it for 1 before Toronto. Anyway I believe it will be worth > discussing these 2 extensions. > > > Best, > > Vicente > > > P.S. EXPLICIT above has the sense given in the standard. > 3. uninitialized default constructed expected<T,E> I know this could be conflictual, but there are a some advantages to doing it. We don't spend time initializing with something we will assign later. This state corresponds to the moved-from state. Initializing it by default to T() is not better initializing to E(). Is expected<Date, error_code> default constructible even if Date is not? Currently it is not the case. There are of course liabilities. We have now the possibility for uninitialized variables, but static analysis tools will help here. 4. About comparisons Outcome doesn't implement comparisons between Outcomes. He pretend that we don't need them. In addition the mix of comparisons and implicit conversion give us some surprising cases as described in Andrzej blog. [1] A gotcha with Optional - https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional We have that std::future is not comparable (as exception_ptr is not comparable). Instead of comparison we could specialize std::less<> if we want to use them in ordered containers. What others think? 5. About implicit conversion from T The implicit conversion from T to expected<T,E> is a consequence of wanting that expected<T,E> should behave like a T. But this is not right. A expected<T,E> is not a T. We have in some way that expected<T,E> is explicitly constructible from E bu the use of make_unexpected(e). If we had only and explicit constructor from T the code will be much more uniform. Either you build it with a modified make_expected or with make_unexpected. In my opinion the implicit conversion from T to expected<T> is a mistake. 5. About the exception to throw std::experimental::expected throw bad_expected_access<E>. I adopted the design of optional and bad_optional_access We could have as well a bad_expected_access_base class as Outcome has. My question is why don't throw directly E? Some are requesting a way to get a specific exception from E, but either there is one exception that works for all and we can set it using some kind of trait or we need to add a trait parameter to expected to the the mapping :( Do we really want this to be configurable? 6. Implicit conversion from E outcome::expected<T,E> outcome::expected<T,E> is implicitly convertible from E when there is no risk of ambiguity. std::expected<T,E> is implicitly convertible from unexpected<E>. What people thing we should have? In Boost? in the standard? Vicente

5 21

[build] [config] check_target_builds and feature.subfeature composition
by Edward Diener 30 May '17

30 May '17

The Boost library config uses the check_target_builds rule to provide build time feature testing. Other Boost libraries use config checks in their own build and test jamfiles. I have found that this works reliably when a particular toolset is used in a normal manner. However when using the feature.subfeature and feature.compose rules to extend the toolset-version designation with a subfeature, such that the toolset designation now becomes toolset-version-subfeature, the use of the check_target_builds rule does not work as expected. In particular the individual check_target_builds rule results are put into a subdirectory based on the toolset-version and not based on the toolset-version-subfeature when toolset subfeature composition is used. I also suspect that the cached value reflects setup. This causes wrong results in tests where the toolset designation uses subfeatures, and a library's jamfile is using config and/or predef checks. As an example My toolset designation looks like: using gcc : 6.3 : some_path ; feature.subfeature toolset gcc : cxxstd : c03 c11 c14 c17 : optional composite propagated ; feature.compose <toolset-gcc:cxxstd>c03 : <cxxflags>-std=c++03 ; feature.compose <toolset-gcc:cxxstd>c11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:cxxstd>c14 : <cxxflags>-std=c++14 ; feature.compose <toolset-gcc:cxxstd>c17 : <cxxflags>-std=c++1z ; A library's test looks like: import ../../config/checks/config : requires ; run some_test.cpp : : : [ requires cxx11_hdr_forward_list ] ; If I run some some_test with toolset=gcc-6.3-c03, the config result for checking if forward list is supported is put into a subdirectory reflecting the toolset-version while the test result will be put into a subdirectory reflecting the toolset-version-subfeature. Subsequently if I run some_test with toolset=gcc-6.3-c11 the config result is taken from the subdirectory reflect the toolset-version even though whether the forward list is supported or not depends very much on the subfeature I am designating as part of the toolset. This naturally causes incorrect results for the test. Is this a known problem ? Is it a problem with Boost Build or is it a problem with how config uses the check_target_builds rule ? I have run into this problem extensively in my testing once I started to use the feature.subfeature ability of Boost Build.

5 9

[outcome] Review of Outcome
by Emil Dotchevski 29 May '17

29 May '17

I. Design There is a need in C++ for dealing with failures without using exceptions. This is not so much driven by actual inefficiencies (as opposed to perceived inefficiencies) of exception handling, but by the fact that not all C++ code in existence is exception-safe, and the fact that some C++ programmers work in environments where exception handling is disabled, as ill-advised such a decision may be. In my opinion the library should drop option<T> and result<T> altogether and should be reduced to outcome<T> only, which can be empty, or hold a T, or hold an exception (but not error code, see below.) This is critical for a library that aims to provide a _common_ general mechanism for dealing with failures in interfaces; providing a rich set of alternatives works against that goal. (It seems desirable to get rid of the empty state too but the discussions during the review period show that this might cause more problems than it solves.) Secondly, it is not a good idea to use error codes or any other value as means to dispatch on different kinds of failures because semantically such dispatch should be static: there is some _code_ which detects the error, and there is some other _code_ that needs to bind it and handle it. This is one reason why in C++ catch dispatches by the static type of the exception objects, not by some exception.what() value. Further, using static types to communicate different kinds of failures allows users to recognize and handle an entire class of errors by means of implicit type conversions, by organizing error types in a hierarchy. For example: struct io_error: virtual std::runtime_error { }; struct read_error: virtual io_error { }; struct write_error: virtual io_error { }; struct file_error: virtual io_error { }; struct file_read_error: virtual file_error, virtual read_error { }; struct parse_error: virtual std::runtime_error { }; struct syntax_error: virtual parse_error { }; With this hierarchy, we can use read_error to handle any kind of read errors (not just file-related), file_error to handle any kind of file failures (read or write), etc. That said, outcome<T> should also be able to transport values, however their purpose should not be to tell _what_ went wrong, but to provide additional information. It must be stressed that such additional information should be decoupled from the classification of the error. For example: outcome<parsed_data> parse_file( char const * file_name ); The above function reads a file and returns some parsed_data -or- stores an exception object in the outcome. What are the possible failures? It may be a file_read_error, but also types unrelated to I/O like std::bad_alloc or syntax_error. Regardless of the type of the failure, the outcome object should be able to transport the file name because it is relevant no matter _what_ went wrong. Incidentally, the need to transport contextual information independently of the error classification exists when throwing exceptions as well, so if outcome<T> can hold exception objects (and allow users to dispatch on their static type, like catch does), the exception objects themselves can take care of holding any additional information, for example by using Boost Exception. II. Implementation In general the library should not shy away from integrating with common Boost facilities in an effort to appeal to people who hate Boost. A Boost library should primarily target Boost users and address their concerns. This includes the testing framework as well as boost/config.hpp where applicable (it is okay to not always include boost/config.hpp, but it should be included to get things like BOOST_NO_EXCEPTIONS and other configuration macros.) The library should use BOOST_ASSERT, though I don't see a problem with not #including boost/assert.hpp if BOOST_ASSERT is already defined (by the user). The library should use BOOST_THROW_EXCEPTION to throw. Like in the case of BOOST_ASSERT, it's fine to not #include boost/throw_exception.hpp if BOOST_THROW_EXCEPTION is already defined. That said, avoiding coupling with individual Boost submodules is desirable in general. Also there is no problem with providing facilities to avoid all Boost coupling in order to support non-Boost users. III. Documentation The documentation makes broad claims about the inefficiency of exception handling which seem to be motivated by a desire to appeal to programmers who hold such beliefs. There is no need to make such generally untrue claims in order to justify the need for Outcome. Other than that the documentation does the job. IV. Verdict Should Outcome be accepted into Boost? NO This obviously applies only to the current state of the library.

3 4

[move] BOOST_RV_REF(TypeWithoutMoveEmulation) parameters
by Groke, Paul 29 May '17

29 May '17

Hi, I'd like to use BOOST_RV_REF, with both C++98 and C++11 compilers, for some sink-functions, with types that are not "move-enabled". I.e. types that the sink can "consume"/"move from" by other means (swapping, calling .release(), ...). Some of them I can - eventually - change to be fully move-enabled, others I can not (e.g. STL classes). I just assumed that this was possible by simply passing the argument with boost::move(arg). Apparently it's not though, because boost::move will return a plain T& for types without move emulation. For the time being I have defined my own helper function template "move_any" that will always return a rv<T>&. Is there such a function that I missed? And if not, would you think it'd make sense to provide one (I certainly think it would)? Regards, Paul Groke

3 5

[outcome] On the design and documentation
by Thomas Heller 28 May '17

28 May '17

Hi Niall (and also probably Vicente) I was following the discussion about expected/outcome/result very closely and I can absolutely see the usefulness of such a library (I explicitly discarded option here). I am not sure if this post should count as a review, mainly because I disagree with the fundamental design decisions (that includes expected as defined in D0323R2) and therefor would cast my vote as in "not ready yet", I hope I can convey my points below. First of all, I don't agree with the strong (conceptual) relationship between optional (be it boost:: or std::experimental) in such a way that expected is a generalization of it. From what I understand, the purpose of expected/outcome/ result is to be used as a mechanism to return the result of a function. As such it should also expose the semantics of it. Fortunately, we already have a (asynchronous) return object standardized (std::future). And this is my basic disagreement here: Why not model expected in the lines of future? With the main points being: - expected being movable only - expected<T,E>::value() should always return by value and invalidate this. - (I would really prefer the color .get though ;)) So the question to Vicente/Niall is: what is the motivation to make it "optional-ish"? Do we have use cases which make this design undesirable? By having these constraints, expected of course needs to have an uninitialized state. As such we'd have the three observers: valid(): true when has_value() || has_error(), false otherwise (for example default constructed, invalidated), has_value() and has_error(). Second, I think Niall raised a valid about outcome being a framework for interoperability (completely orthogonal to the first point). However, I totally miss this from the proposed library, most pressing are non intrusive mechanisms. For that purpose I postulate, that a mechanism to transform between different unexpected results, that is: various error codes etc. However, for that to work, one would of course need a properly defined concept, for example, as Vicente suggested "EitherValue", and a mechanism to coerce one error type into another, maybe through ADL, or traits specialization or whatever. With that in place, one could simply define the different EitherValue types, there is no need that everything needs to be in the form of "basic_XXX". For the library under review, this would be perfectly sufficient: template <typename T, typename E> class expected; template <typename T> using result = expected<T, extended_error_info>; template <typename T> using outcome = expected<T, variant<extended_error_info, exception_ptr>>; That is, given that we have either a value or unexpected, we can convert expected<T, E1> to expected<U, E2> if T is convertible to U and E1 "coercable" (with whichever mechanism) to E2. If we then have a generic mechanism to get from a (possibly user defined "E") to an exception, I completely miss the point of the outcome template. Furthermore, I believe that .value/.error should really have a narrow contract, that is that it is UB to call those functions if the respective types are not held (easy to catch this in a debug build...). Why? Probably just a micro optimization, but consider the canonical usage: auto r = some_function_returning_expected(...); if (r.has_value()) // Do something with the value else // An error occurred, PANIC In both branches, we know exactly what's in there ... so why check again when getting the state out? I don't get the "reinterpret_cast" argument. I am one of the persons that believe that UB is a necessary evil for some optimizations... All optimizations can then easily be put as implementation details and the generic expected<T, E> will probably suffice for most use cases, for everything else, we can implement special types which conform to our concepts and implement the error conversion mechanisms. This will most likely also work with different APIs/ABIs. Last but not least, I wanted to give some feedback on the proposed Boost.Outcome documentation. At the very least, I find it highly confusing. When I open its "landing page", I get no idea about the following: - What is the purpose of the library? - Why/when should I use it? - What should I look into next? >From the front page, it looks like a implementation of expected, but only talks about the outcome template, it is very hard to find the documentation for the other three types result, outcome and option. Yet, the documentation explicitly warns about it being unstable and suggests to use its refinements. Useful information is spread across the whole documentation, there is no easy way to find the requirements on T or E. The reference section is anything but complete and doesn't convey any useful information. I did not really look at the actual implementation of the proposed library. I cloned the git repository and had a quick glance, but to be honest, I got lost very early, I have no idea where to start looking first. Cheers, Thomas

6 15

[outcome] outcome without empty state?
by Andrzej Krzemienski 28 May '17

28 May '17

Niall, What do you think about the following alternate interface of outcome types? 1. Remove option<T> altogether. 2. result<T> (and outcome<T>) does not have a separate empty state. 3. A default-constructed result<T> is initialized as if `result<T>{error_code_extended{}}`. 4. Function r.empty() is implemented as `r.has_error() && !error()`. 5. Framework requires that type E in `expected<T, E>` is default-constructible, and its default-constructed value represents no error condition (already the case for exception_ptr, error_code). The rationale behind this is my assumption that `option<T>` is not as useful as the other types. (Or can you give an example to the contrary?) That there was no initial business need for an empty state, and the examples that illustrate its usefulness are just exploring how we can make use of it now that it is there. (Or am I wrong here?) I noticed a number of people report negative feedback about this empty state. Getting rid of it would take result<T> closer to "either T or reason for failure". What do you think? Regards, &rzej;

6 27