- Boost - lists.boost.org

1.73.0 Beta Deadline this Wednesday 4/8
by Marshall Clow 09 Apr '20

09 Apr '20

The deadline for major changes has passed. Upcoming dates: 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" -- Marshall

6 16

boost [math] excessive warnings via [lexical_cast] from [date_time] (and others) for clang 3.4?
by Jeff Garland 08 Apr '20

08 Apr '20

In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue? Or will this soon be a real issue? ../boost/math/tools/config.hpp:42:9: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] ../boost/math/tools/config.hpp:43:9: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] ../boost/math/tools/config.hpp:44:9: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] Full examples https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/output/teeks99-dkr-dc3-4-98…

5 23

Gsod20 interest
by Damian Vicino 08 Apr '20

08 Apr '20

Hi, I'm wondering if there is interest in submitting boost as a potential org for Google season of docs (https://developers.google.com/season-of-docs) Also, if someone would like to be mentor on it, that would be great to know too. Best regards, Damian

2 1

Boost local unix domain example for IPC
by Jupiter 08 Apr '20

08 Apr '20

Hi, I am doing boost local unix domain for IPC, I midified the code based on sample code from boost_asio/example/local/stream_server.cpp, I am a little bit puzzled for errors calling different async_read, if I call original code using shared_from_this() it works fine: boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData), boost::bind(&session::HandleRead, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); But if I tried to run a following lambda function which works in in my other boost asio TCP socket, it got an error "Operation canceled", what I could be missing here? Or do I have fundamontal problems in the lambda function I used for other TCP socket programs? boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData, sizeof(this->mData)), [=](const boost::system::error_code &status, const uint32_t size) {this->HandleRead(status, size);}); Thank you. Kind regards, - jh

2 2

[xpressive] Where are the names in the c_ctype.h file coming from
by Edward Diener 07 Apr '20

07 Apr '20

In the xpressive header file c_ctype.h there are names such as _ALPHA, _UPPER, _LOWER, _DIGIT etc. Where are these names declared or defined ? I searched through all the Boost libraries and did not find any of these names declared or defined anywhere. Are they supposed to be part of some C++ standard header file ?

1 0

Asio, gcc and -fconcepts
by Richard Hodges 07 Apr '20

07 Apr '20

Dear all, With the upcoming Boost 1.73 release imminent, I felt it was worthwhile pointing out that latest gcc has a problem with Asio if the `-fconcepts` command line flag is set. There is an issue in the Boost.Asio repo here relating to the manifestation of the bug in MSVC: https://github.com/boostorg/asio/issues/312 and an issue here in the Boost.Beast repo: https://github.com/boostorg/beast/issues/1884 It seems that the file boost/asio/detail/config.hpp was written when concepts support was not widespread and still in the concepts.ts stage. The syntax and capabilities of concepts were subtly changed during standardisation, with gcc and MSVC only supporting the C++20 dialect. Thus, compiling an Asio-based program with concepts enabled in either of gcc or MSVC fails unconditionally. I'm wondering if anyone has Chris' ear and might ask him to indulge us with a fix prior to the 1.73 release. I fear that by the time Boost 1.73 is in mainstream use, C++20 will be upon us we'll see an increase in issues and a loss of reputation as a result. Thanks for your time, Sincerely, -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 4

[Performance of circular_buffer vs Queue][Multithreading may be broken]
by Jan Hafer 04 Apr '20

04 Apr '20

Dear Boost developer, I found the circular buffer to be slower than std::queue for multithreading except in the case of a single thread (where it is notably faster). I am using resize() to have the expected size filled as in vector. Is this behavior expected or documented anywhere? What kind of speedup is to be expected against the std::queue implementation? If there is none, then what is the purpose of circular buffer? I do also have broken code on a multithreaded application that worked fine before. I do pass the circular buffer as reference via functions from file scope, which in combination with the threads (initially starting elsewhere) somehow broke the code. Do you do regular benchmarks against other implementations? I dont see linked graphs on your homepage. Regards, Jan

7 10

[1.73][thread] Merge to master and apply PRs
by Andrey Semashev 04 Apr '20

04 Apr '20

Hi, There are a number of fixes in Boost.Thread develop that I would like to see in 1.73, but they are not merged to master. The last commit to develop was in Dec 2019, so plenty of time has passed for testing. I'd like to ask someone to merge develop to master. https://github.com/boostorg/thread/issues/311 Also, there are two PRs hanging for quite some time that I would also like to see in 1.73: https://github.com/boostorg/thread/pull/309 https://github.com/boostorg/thread/pull/310 I'd like to ask someone with merge permissions to have a look and merge them (first to develop, and then to master, after testing). I tried pinging Vicente, but he is not responding. Most of the changes in develop and the PRs are aimed to resolve various warnings generated by Boost.Thread, including using deprecated features of Boost.Bind, Boost.WinAPI and C++. Thanks.

1 0

Re: [boost] Linking libboost_python.so to libpython
by Peter Dimov 03 Apr '20

03 Apr '20

> That's why you weren't getting the error before 1.72, but not the reason > why libboost_serialization ends up with the different property sets. FWIW, my Travis build/install of --with-mpi works: https://travis-ci.org/github/boostorg/boost_install/jobs/669821455 and I can't find the place that's setting <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config.

2 1

Linking libboost_python.so to libpython
by Jonathan Wakely 03 Apr '20

03 Apr '20

tools/build/src/tools/python.jam says: # On *nix, we do not want to link either Boost.Python or Python extensions # to libpython, because the Python interpreter itself provides all those # symbols. If we linked to libpython, we would get duplicate symbols. So # declare two targets -- one for building extensions and another for # embedding. Why would that give duplicate symbols? Wouldn't ELF symbol interposition mean that only one is used? Why would it be a problem to link to libpython? In Fedora's Boost RPM packages we *do* link libboost_python.so to the system libpython (and we don't get any problems). But to do this, we have these two local patches: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.57.0-python-… and then to make it link to libpython3.7m.so (rather than libpython3.7.so) we have this patch to pass the "m" into the Boost build: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.66.0-python-… I'd prefer not to need these local hacks. Would the upstream Boost.Python consider making changes so that libboost_python.so can be (optionally) linked to libpython? Is there a cleaner way to do this than those patches?

5 12