March 2019 - Boost - lists.preview.boost.org

[format] Allow the format library to use std::optional
by Sean Farrow 30 Mar '19

30 Mar '19

Hi, Would be possible/desired to allow boost.format to use std::optional instead of boost.optional when compiling a C++17 project. I've raised a GitHub issue to resolve this: https://github.com/boostorg/format/issues/63 I would be happy to do this if it were warranted. Kind regards Sean.

1 0

Re: [boost] [Boost-build] Building Boost 1.69 with Visual Studio 1.69
by Steven Watanabe 29 Mar '19

29 Mar '19

AMDG On 3/27/19 12:02 PM, Paul Bristow wrote: >> <snip> > I was fully up-to-date on develop yesterday, and installed git a week ago (new machine ;-) ). > The current revision of Boost.Build in develop should be e22a75c8 (March 18) > I am also slightly concerned that specifying the cl.exe fully may not be updated when Visual studio is updated, as happens today? > But it does seem to using the new compiler version, even though the full cl.exe file specification is no longer correct. > Similarly vsvarsall.bat location in the set command will change. > > But I am getting Boost library files built OK for several compilers and versions, so that's progress. > Hmm. It looks like VS2019 isn't being autodetected. It seems to be working for Tom's test runners. Maybe see what you get from: vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -version "[16.0,17.0)" (This is how Boost.Build tries to detect VS2019.) In Christ, Steven Watanabe

6 12

Regarding BOOST.Astronomy
by Sarthak Singhal 29 Mar '19

29 Mar '19

Hello everyone, I am not able to understand what exactly is to be done to complete the parser for FITS and I have also tried understanding the codebase but I am not getting what is the work done till now. Can you also provide some resources? Thanking you Sarthak Singhal

4 3

[visibility][test][osx] visibility warnings with 1.70beta
by Raffi Enficiaud 28 Mar '19

28 Mar '19

Hi, I have a side project that requires boost.test and I thought it is the right time to use the beta build of 1.70. At link time for my project (in this case a simple boost.test module), I have tons of warnings like the following: ld: warning: direct access in function 'boost::unit_test::decorator::depends_on::apply(boost::unit_test::test_unit&)' from file '/Users/raffi/from-big-laptop/code/software_workshop/sw_thirdparties/osx/boost_1_70_0_b1/lib/libboost_unit_test_framework-xgcc42-mt-x64-1_70.a(decorator.o)' to global weak symbol 'boost::unit_test::basic_cstring<char const>::null_str()::null' from file '/Users/raffi/code/mpi/mpi_kmeans/build/MPI-Kmeans.build/Debug/test_mpi_kmeans.build/Objects-normal/x86_64/test_cls_and_func_impl.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. running Xcode 10.1 on 10.14/mojave. I am building boost like this: ./b2 \ cflags="-mmacosx-version-min=10.10" \ cxxflags="-std=c++11 -stdlib=libc++ -mmacosx-version-min=10.10" \ mflags="-mmacosx-version-min=10.10" \ mmflags="-mmacosx-version-min=10.10" \ linkflags="-stdlib=libc++ -mmacosx-version-min=10.10" \ --prefix=`pwd`/../${build_folder} \ --without-log \ --layout=versioned \ install Each of the files that are being built in my project and that are raising the warning have a compilation command like this: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DBOOST_ALL_NO_LIB -DKMEANS_VERBOSE=0 -I/Users/raffi/code/mpi/mpi_kmeans/include -I/Users/raffi/code/mpi/mpi_kmeans/applications/include -isystem /Users/raffi/from-big-laptop/code/software_workshop/sw_thirdparties/osx/boost_1_70_0_b1/include/boost-1_70 -O3 -DNDEBUG -std=gnu++11 -o CMakeFiles/test_mpi_kmeans.dir/test/test_kmeans.cpp.o -c /Users/raffi/code/mpi/mpi_kmeans/test/test_kmeans.cpp which is pretty much what I had so far and before 1.70. Boost.test is using BOOST_SYMBOL_VISIBLE to make a symbol public, including the static build variant. Why does the linker say """ This was likely caused by different translation units being compiled with different visibility settings. """ is completely unclear to me. How can I inspect what b2 emits as compilation command line for further debugging? All those visibility issues are causing me a lot of headache :) Thanks! Raffi

3 5

Gsod19 interest
by Damian Vicino 27 Mar '19

27 Mar '19

I'm wondering if there is interest to make boost participate in the Google season of docs. The program is similar to Google summer of code in many ways, but the outcome is production of documentation. It Details: g.co/seasonofdocs <https://developers.google.com/season-of-docs/>

5 15

[GSOC 2019]
by shehab alaa 27 Mar '19

27 Mar '19

Hi, I’m student willing to participate in GSOC 2019. I have finished my competency test for Boost.uBLAS and I have interest in projects 2 (Adding new numerical linear and multilinear algebra algorithms).So I’m writing looking for mentor who have interest to guide me. And here is my GitHub link for competency test https://github.com/Shehabalaa/CompetencyTest Best regards, Shehab Alaa

2 1

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

26 Mar '19

> > 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. Thanks!

6 8

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