- Boost - lists.boost.org

Building Boost 1.69 with Visual Studio 1.69
by Trueman, Chris 26 Mar '19

26 Mar '19

Maybe I'm getting ahead of myself given the recent topic about picking a version number for the latest MSVC toolset but I'm having trouble building boost 1.69 with Visual Studio 2019 preview. I blindly assumed the toolset was 14.20 (given the directory where cl.exe is found). Letting b2 determine the version yields vc141 in the lib names. Trying to force 142 with: using msvc : 14.2 : <path to cl.exe> ; in project-config.jam yields errors about unescaped characters. Suggestions welcomed. Chris. INTELLICORP LEGAL NOTICE: This E-Mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you received this message in error, please notify the sender immediately by replying to this message, and then delete it.

6 11

[fibers] Great amount of errors and warnings raising out of valgrind
by Stephan Menzel 26 Mar '19

26 Mar '19

Hello all, I was just in the process of doing vagrind runs on a server process that recently switched to an architecture using boost fibers. Specifically buffered_channel as a number of worker fibers run in a thread. The process was regularily checked with valgrind before but now I'm getting overwhelmed by the amount of messages. Uninitialized values, invalid writes and reads all across the board and all seem to come out of fibers. I see no direct mention of my code. A few samples: ==8024== Thread 1: ==8024== Conditional jump or move depends on uninitialised value(s) ==8024== at 0x454F98: unique (circular_list_algorithms.hpp:112) ==8024== by 0x454F98: empty (list.hpp:540) ==8024== by 0x454F98: boost::fibers::buffered_channel<std::function<void ()> >::close() (buffered_channel.hp ==8024== by 0x454FDB: boost::fibers::buffered_channel<std::function<void ()> >::~buffered_channel() (buffere ==8024== by 0x4376BF: operator() (unique_ptr.h:78) ==8024== Invalid read of size 8 ==8024== at 0x9C1756: boost::fibers::context::~context() (in /my_server) ==8024== by 0x9C31CF: boost::fibers::main_context::~main_context() (in /my_server) ==8024== by 0x6B0B85E: __call_tls_dtors (in /usr/lib64/libc-2.26.so) ==8024== by 0x5D49558: start_thread (in /usr/lib64/libpthread-2.26.so) ==8024== by 0x6BC92FE: clone (in /usr/lib64/libc-2.26.so) ==8024== Address 0xa6f0010 is 32 bytes inside a block of size 232 alloc'd ==8024== at 0x4C2D1DA: operator new(unsigned long) (vg_replace_malloc.c:334) and thousands more similar to this. Now, is there something about fibers that causes this as false positives (such as valgrind not knowing about fibers or coroutines) or is there an underlying problem here? This is running on AWS Linux 2, built with gcc 7.3, boost 1.69. Multithreaded release build with debug info. Nothing out of the ordinary. I am a bit concerned about this and wanted to let the list know. Can provide more output on demand. Cheers, Stephan

2 2

Re: [boost] [review][variant2] Variant2 Review Starts April 1
by dariomt＠gmail.com 26 Mar '19

26 Mar '19

> > On Mon, 25 Mar 2019 at 17:18, dariomt--- via Boost <boost(a)lists.boost.org> > wrote: > > > ... as I would expect many more current users of the venerable > > boost::variant than of its much younger cousin std::variant. > > > > Why do you expect that and do you think that will stay that way? Well, Boost.Variant has been around so much more time than std::variant, so this seems obvious to me. For new code, maybe people will just use std::variant, but there's more old code than new code. Also, I'd say the cost of migrating from Boost.Variant to std::variant is non-zero, and the benefits are not clear (to me), so I'd expect not many people to undergo this migration. My feeling is that the library is aimed at current users of std::variant, offering a "better" pin-compatible alternative, but if I'm using Boost.Variant I believe I also should be considered a potential user. That's why I'm curious about the Boost.Variant2 review, we might get more clarity by comparing the three versions, and we may even get guidance for a migration path from Boost.Variant to Boost.Variant2. > My > personal feeling is that C++17-use is picking up at break-neck speed. For > good or for worse, although there appears to be a lot of controversy over a > (any) variant [and there are quite some quite different implementations > around], the std::variant is the one in the std, which seems to give it a > head start. Well, in my (limited) experience Boost is ubiquitous, so being in std is not that much of a head start. > In my view there can only be one objective with boost varant2, > and that is if it is decided [here] that it is (much) better than the > current std::variant, the C++20 std::variant should be/become the proposed > boost::variant2. > > degski > I wonder if code dealing explicitly with valueless_by_exception() will break if you make this change.

2 1

Re: [boost] [review][variant2] Variant2 Review Starts April 1
by dariomt＠gmail.com 26 Mar '19

26 Mar '19

> > dariomt--- wrote: > > > The class boost::variant2::variant<T...> is an almost conforming > > > implementation of std::variant with the following differences: > > > > > > I see the useful comparison to std::variant in the doc, however I'm > using > > boost::variant extensively in my code. > > > > It would be very useful to have also a short comparison to > boost::variant > > in the doc, as I would expect many more current users of the venerable > > boost::variant than of its much younger cousin std::variant. > > The main difference is that Variant2 is a pin-compatible replacement for > std::variant, whereas Boost.Variant isn't (at least for now). So it's > easier > to switch from std::variant to Variant2 and back (depending f.ex. on > whether > std::variant is available.) > > The second most important difference would probably be the fact that > Boost.Variant may do heap allocations. > This is useful info, thanks! I understand that the main objective is to offer a "better" std::variant, but as a user of Boost.Variant wondering "Should I consider migrating to Boost.Variant2?", I would expect a section in the doc addressing this question.

1 0

Which forum to handle issues/questions regarding libraries
by Robert Ramey 25 Mar '19

25 Mar '19

I've been studying the boost multiprecision library and I have a few questions relating to various aspects of said library. These questions are quite specific to that library and I'm not sure that they are of wider interest other than to a couple people. So I'm wondering if it would be better to post these as library issues on github or on this list or both. It used to be simple but now we have at least three places to discuss these things: slack, here and github issues for the library in question. Also sometimes some PRs can highlight differences which can get ironed out in the PR comments. Do we have a consensus as to the preferred way to select the correct forum? Robert Ramey

5 4

Looking for a Mentor: GSoC 19: Boost.uBLAS: Linear and Multilinear...: Project 1 and 2
by forcha glen 24 Mar '19

24 Mar '19

Hello, I am interested in any of these two projects. I do not yet have a mentor. I need mentor. Regards, Glen

2 1

Re: [boost] Master branch open for merging
by Nikita Kniazev 22 Mar '19

22 Mar '19

I would like to merge Spirit to master. The develop contains bunch of minor changes, but I important ones are: Endian namespace pollution and macros conflict fixes: https://github.com/boostorg/spirit/commit/6c258d506c2bbadccdb9f25e481984aca… https://github.com/boostorg/spirit/commit/74c0ec310a2345cb95ffb947327f69007… https://github.com/boostorg/spirit/commit/9d48b5a23197bbbcc4a3a8990c164b1cf… GCC 6/7 regression avoidance: https://github.com/boostorg/spirit/commit/8bd9b6ece40f9324a902bb0f726e785ff… The regression matrix is green for two weeks.

2 1

[release] Boost 1.70.0 Beta 1 is now available
by Marshall Clow 22 Mar '19

22 Mar '19

[ resending with a non-empty subject line ] Boost release 1.70.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.70.0.beta1/source/> The SHA256 checksums are as follows: dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 14

[Process] Proposed solution for posix pipes staying open
by Bills, Jason M 22 Mar '19

22 Mar '19

Hello, I'm new to Boost and looking for some help on the right process to propose patches. I'm running in an embedded Linux environment (OpenBMC) using Boost 1.69.0 and just switched a couple of std::system() calls to boost::process::system() calls. After making this change, I noticed that each time my process executed the bp::system() call, I would get an extra pipe fd in my /proc/<pid>/fd list. I did some debugging and have found a possible solution for this issue in the Boost.Process posix headers that I would like to propose. What is the right forum or process to post my patch (post it here, github pull request, etc.)? Thanks! -Jason

2 2

questions about boost multiprecision
by Robert Ramey 22 Mar '19

22 Mar '19

I'm looking more carefully at Boost Multiprecision than I have in the past and have a couple of questions: It's not clear to me how errors are handled. For example, what happens in a divide by zero? Or what happens when a result overflows. I'm aware that this will likely vary depending on whether the arguments are arbitrary precision made a runtime or a precision fixed at compile time. In any case, looking through the manual I can't find this information. Of course this package is so ambitious, that it's possible that I've missed it but in that case a pointer would be appreciated. Spending some time on this makes me appreciate what an incredibly ambitious accomplishment this is. It's really unbelievable. I would be curious how frequently various parts of the package are used. Robert Ramey

4 4