- Boost - lists.boost.org

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