- Boost-users - lists.preview.boost.org

boost::process::win32_launch(...) with unicode working directory - Urgent
by Chandrasekhar B 04 Jun '18

04 Jun '18

Dear Users, I have trouble using the following boost api. I am developing application for Non English OS. The working directory is non-english for this case. If I set the working directory to Japanese or any other non-english language, the process does not start. I have few files that need to be read from the working directory. however, if I launch the process from the cmd line (whose path is again some Unicode text) the process launches fine. boost::process:win32_launch(const Executable &exe, const Arguments &args, const Win32_Context &ctx) is there any way to support unicode path for working directory within boost? Regards Chandrasekhar

1 0

How to build shared boost with clang-win?
by JR Cary 03 Jun '18

03 Jun '18

Windows 7 VSS2017 (1911) LLVM-6.0.0-win64 ./bootstrap.bat (works) ./b2 -d+2 -q toolset=clang-win runtime-link=shared link=shared cxxflags='/std:c++14 /EHsc /MD' address-model=64 threading=multi variant=release -s NO_COMPRESSION=1 --layout=system --abbreviate-paths -j1 --without-python --without-mpi --without-log --without-math stage fails at clang-linux.link.dll bin.v2\libs\atomic\build\clng-lnx-win\rls\thrd-mlt\boost_atomic.dll "clang++" -o "bin.v2\libs\atomic\build\clng-lnx-win\rls\thrd-mlt\boost_atomic.dll" -Wl,-soname -Wl,boost_atomic.dll -shared -Wl,--start-group "bin.v2\libs\atomic\build\clng-lnx-win\rls\thrd-mlt\lockpool.obj" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -m64 -pthread It looks like clang-win is trying to use clang++ to link? Should it no use clang-cl? Thanks....John Cary

1 0

Plans to add parameter parsing in Beast?
by David Demelier 30 May '18

30 May '18

Hello, I'm trying to use Beast, it works fine and looks promising. Unfortunately, it looks like (unless I'm wrong) that there is no facilities to parse URL parameters or POST data. Such as /foo&option1=1&option2=2 Or simply form data: option1=1&option2=2 Are there plans to add such things or is definitely a non-goal of Boost Beast? Regards, -- David

2 2

Boost::Log memory allocation
by Olivier Tristan 29 May '18

29 May '18

Hi, I was wondering if it is possible to avoid allocation in the thread trying to log stuff ? I thought that using asynchronous_sink and bounded_fifo_queue with drop_on_overflow would be enough but it do not look like to be the case. Thanks ! -- Olivier Tristan Research & Development www.uvi.net

1 0

boost-iostreams problem
by Theodore Papadopoulo 28 May '18

28 May '18

Hi, I'm trying to use boost_iostream in a way that is probably not intented. My use case is the following, I have a C++ stream. I want to read its first bytes to determine if its gzip or Bzip2 or none of those, putback the characters to the stream and then create the appropriate pipeline to read the stream. Ideally, I'd then restart the procedure, so that I can incrementally build a pipeline based on the successive magic numbers read at the begining of the stream after different level of decoding. Imagine a file that has been gzipped and uuencoded. Let's call its stream ifs. Reading the first bytes of ifs, I would detect that it's an uuencoded file, so I construct a pipeline ifs1 = ifs | uudecode. Reading the first bytes of ifs1, I would detect that it's a gzipped file, and will construct a new pipeline ifs2 = ifs | uuencode | gzip (the reverse ordering for reading pipelines does not help here, but I can manage that). And so on.... Unfortunately, this does not work as I'm expecting it. The attached code is a small example showing the problem. When, reading the stream after having pushed the gzip filter (line 23), I get an exception. boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::iostreams::gzip_error> > Digging a little with gdb seems to show that the putback buffer is somehow lost, so the gzip filter does not read the proper header and hence the exception. The raw in.read does not throw exceptions but returns random bytes after the first 1f.... What is strange is that if I do the sequence: in.push(file); read(in,buffer,1); putback(in,buffer[0]); in.pop(); in.push(file); read(in,buffer,1); std::cout << std::hex << static_cast<int>(static_cast<unsigned char>(buffer[0])) << std::endl; putback(in,buffer[0]); The second read correctly reads the character put back (1f), but the second putback triggers an exception (putback buffer full). If the first read/putback is done directly on file, everything works as expected. I'm really stuck at this point, so any help would be welcome.... I hope there is a way to use boost_iostreams to achieve what I want to do. Thank's in advance for any clue on how to solve this... Theo.

1 0

[asio] continuous reads into streambuf
by Stephan Menzel 25 May '18

25 May '18

Hello all, once again I find myself struggling with asio streambufs but wanted to ask here before chicken out to char buffers again. My problem is that I cannot read more than one protocol loop successfully. I got a TCP connection here that continuously receives messages on a simple protocol like that: header_size CRLF header (contains payload size) payload <repeat> I thought this is a prime use case for reading into a streambuf as I can easily deal with additional data being in there and the client pushing as fast as it can. Here is what I do (simplified quite a bit, sorry for copy and paste and simplify errors): (m_socket and m_streambuf are only used by one io_context, one thread, no races as far as I can tell) void read_header_size() { asio::async_read_until(m_socket, m_streambuf, "\r\n", [self](const boost::system::error_code, const std::size_t) { // < handle error skipped > std::string hsizestr; hsizestr.reserve(32); { std::istream is(&self->m_streambuf); std::getline(is, hsizestr); } std::size_t header_size = parse(hsizestr); self->read_header(header_size); }); } void read_header(const std::size_t n_header_size) { asio::async_read(m_socket, m_streambuf, boost::asio::transfer_exactly(n_header_size), [self, packet, n_header_size](const boost::system::error_code, const std::size_t) { // < handle error skipped > // Tried two versions of parsing the header (manual consume and istreams of various sorts) // manual consume: size_t payload_size = parse_header(n_streambuf.data().data(), n_header_size)) { n_streambuf.consume(n_header_size); self->read_payload(payload_size); }); } void read_payload(const std::size_t n_payload_size) { asio::async_read(m_socket, m_streambuf, boost::asio::transfer_exactly(payload_size), [self, n_packet, packet_size](const boost::system::error_code, const std::size_t) { // < handle error skipped > { std::istream is(&self->m_streambuf, std::ios::binary); is.read(target_buffer, target_buffer_size); // target buffer is elsewhere and well guarded } // read next message self->read_header_size(); }); } When I run this and make sure the client pushes at least 2 packets I can safely receive and process the first but after that the next asnc_read() in read_header never returns. As in never calls its handler. From debugging and looking at the streambuf I can reasonably assume the buffer contains all the data after the first async_read_until because the packages are very small (only about 60 bytes total). This leads me to believe the transfer_exactly don't return unless something is actually really transferred. But if such is the case, why does the first loop succeed? I am quite lost here. If anybody has some suggestion it is much appreciated. Thanks a bunch! Stephan

4 9

Boost Process continuously read output
by Surya Kiran Gullapalli 16 May '18

16 May '18

Hi, I'm trying to read outputs/logs from different processes and display them in a GUI. The processes will be running for long time and produce huge output. I'm planning to stream the output from those processes and display them according to my needs. All the while allow my gui application to take user inputs and perform other actions. What I've done here is, from main thread launch two threads for each process. One for launching the process and another for reading output from the process. This is the solution I've come up thus far. // Process Class class MyProcess { namespace bp = boost::process; boost::asio::io_service mService; // member variable of the class bp::ipstream mStream // member variable of the class std::thread mProcessThread, mReaderThread // member variables of the class. public void launch(); }; void MyProcess::launch() { mReaderThread = std::thread([&](){ std::string line; while(getline(mStream, line)) { std::cout << line << std::endl; } }); mProcessThread = std::thread([&]() { auto c = boost::child ("/path/of/executable", bp::std_out > mStream, mService); mService.run(); mStream.pipe().close(); } } // Main Gui class class MyGui { MyProcess process; void launchProcess(); } MyGui::launchProcess() { process.launch(); doSomethingElse(); } The program is working as expected so far. But I'm not sure if this is the correct solution. Please let me know if there's any alternative/better/correct solution Thanks, Surya

2 3

how to add comments to boost property tree while export in xml file
by neelam baliyan 16 May '18

16 May '18

Hi All, I have read and store my complete configuration file in to boost property tree, now I want to export it to a xml file which i can do via function write_xml(). I wanted to add some comments inside my exported xml file. Please help me to know, how to add comments inside xml file while exporting data from boost property tree. Thanks & Regards Neelam

2 3

Boost and Intellisense
by Leo Cacciari 16 May '18

16 May '18

Hi, I'm developing a windows application using boost libraries. Unfurtunately, some parameters of it are totally out of my control, nor I have the leverage needed to change it. Namely, - the application *must* use Visual C++ 9.0 runtime - the IDE to be used is capped at Visual Studio 2013 - to avoid problems with other related projects, the boost release should be 1.54.0 (here I have a modicum of liberty, as far as the previous two conditions are satisfied) I may live whit all of the above, however Intellisense has some glitches that are annoying me. For one, it appears unable to recognize the boost::asio::ip namespace. If I define a variable as, for instance boost::asio::ip::udp::endpoint ep; Intellisense marks 'ip' in red and keeps saying that ep is undefined (and consequently doesn't offer completion for its methods). I have tried including directly boost/asio/ip/udp.hpp and also putting an "using boost::asio::ip::udp" before the above definition as in #include <boost/asio/ip/udp.hpp> using boost::asio::ip::udp; udp::endpoint ep; but nothing changes (I'll gladly post a screenshot if I knew which is the accepted way to post images to this list). It should be noted that, aside from this and some analogous problems, Intellisense works fine, making the above even more annoying. Does anyone have a solution to this problem that do not violate the aforementioned constraints? Thanks in avance lc -- Leo Cacciari Aliae nationes servitutem pati possunt. Populi Romani est propria libertas.

3 3

phoenix: BOOST_PHOENIX_NO_VARIADIC_EXPRESSION purpose
by MM 10 May '18

10 May '18

Hello (Thomas Heller, Joel de Guzman :-) ) In /usr/include/boost/phoenix/object/construct.hpp, there appears this preprocessor test on this macro BOOST_PHOENIX_NO_VARIADIC_EXPRESSION whereby the code either: 1. includes boost/phoenix/object/detail/cpp03/construct_expr.hpp , or 2. defines a expression inline Is that macro used to workaround some compiler limitations (and/or c++ std version) back in the day? I work with g++7 and std=c++14, and boost 1.64, and yet somehow boost/phoenix/object/detail/cpp03/construct_expr.hpp is included, and somewhere down the line a compilation error happens. The cpp03 is unnerving. Rds, MM

2 1

Boost Graph Library(biconnected_components) issue
by Meghana.M Reddy 07 May '18

07 May '18

Hi, I am working on the Boost Graph Library, currently trying to create an interface of the biconnected_components method to a Python code. I used the example code available here <https://www.boost.org/doc/libs/1_67_0/libs/graph/example/biconnected_compon…> for the method and modified it for my purpose. The template of the method is here <https://www.boost.org/doc/libs/1_67_0/libs/graph/doc/biconnected_components…>. The final code seems fine but I get an error while compiling it. And the errors are related to adjacency.hpp which I have not changed so I'm confused as to what the exact problem is. Hoping someone can help me out. My code: class BoostGraph { private: typedef typename boost::adjacency_list< OutEdgeListS, VertexListS, DirectedS, boost::property<boost::vertex_index_t, v_index>, EdgeProperty, boost::no_property, EdgeListS> adjacency_list; typedef typename boost::property_map<adjacency_list, boost::edge_index_t>::type components; public: adjacency_list graph; std::vector<v_index> bc_tree() { components components_bc = get(boost::edge_index, graph); std::size_t num_comps = biconnected_components(graph, components_bc); std::cerr << "Found " << num_comps << " biconnected components.\n"; std::vector<vertex_descriptor> art_points; articulation_points(graph, std::back_inserter(art_points)); std::cerr << "Found " << art_points.size() << " articulation points.\n"; std::vector<v_index> to_return; return to_return; } The error I'm getting: build/cythonized/sage/graphs/base/boost_graph.cpp:3730:26: required from here /home/meghana/Documents/sage_gsoc/sage_may/sage/local/ include/boost/graph/detail/adjacency_list.hpp:2696:29: error: forming reference to void typedef value_type& reference; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/ include/boost/graph/detail/adjacency_list.hpp:2697:35: error: forming reference to void typedef const value_type& const_reference; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/ include/boost/graph/detail/adjacency_list.hpp:2701:61: error: forming reference to void typename Graph::vertex_descriptor,Property,Tag> type; ^ /home/meghana/Documents/sage_gsoc/sage_may/sage/local/ include/boost/graph/detail/adjacency_list.hpp:2704:68: error: forming reference to void typename Graph::vertex_descriptor,const Property, Tag> const_type; ^ error: command 'gcc' failed with exit status 1 Makefile:33: recipe for target 'sage' failed make: *** [sage] Error 1 Thank you, Meghana

1 0

Installing pre-built binaries on Windows with Docker
by Matthew Berry 04 May '18

04 May '18

Hi, I tried installing pre-built 1.67 binaries from https://dl.bintray.com/boostorg/release/1.67.0/binaries/ in a Windows Server Docker container but am running into an issue where the installation does not complete. I ran the installer exe in silent mode. A lot of the files including headers are installed, but not the lib directory with the binaries. The Inno Setup log does not indicate an error, it just stops writing in the middle of the installation. Does anyone know why installation does not complete? Has anyone been able to install pre-built libraries in a Windows Docker container? Any help would be appreciated. Thanks, Matt

2 1

Why is BOOST_OS_WINDOWS defined on Linux
by David Demelier 04 May '18

04 May '18

Hello, Everything is in the title, the following code compiles and shows "Windows" even though I'm running Fedora 28. I can't understand. #include <iostream> #include <boost/predef.h> int main() { #if defined(BOOST_OS_WINDOWS) puts("Windows"); #endif } I'm using Boost 1.66 with GCC 8.0.1. Regards, -- David

3 5

Bi-Directional Links in call to Push-Relabel Max Flow (UNCLASSIFIED)
by Glover, Anthony E CTR USARMY RDECOM (US) 03 May '18

03 May '18

CLASSIFICATION: UNCLASSIFIED Hello, I am new to the Boost Graph library and had a question concerning the Push-Relabel Max Flow method. From the documentation, it states: The CapacityEdgeMap argument cap must map each edge in E to a positive number, and each edge in ET to 0. >From looking at the examples provided, it appears that an edge is added with some non-zero capacity and then the reverse edge is created with a capacity of 0 as the documentation states is needed. However, if I truly want a reverse edge with non-zero capacity, it appears that I have to create a second pair of edges going the other direction. I end up creating 4 total edges to handle the bi-directional flow capacity. Is that truly how the graph should be configured in order to use the method? Maybe I'm just not using it as designed. Thank You, Tony CLASSIFICATION: UNCLASSIFIED

1 0

Veracode Scan
by Abhijit Dutta 03 May '18

03 May '18

Hi There, As part of release practice in our org., we have run Veracode (static) scan on our application which uses BOOST. We got good amount of error pointing to the BOOST libraries. Detecting the false positives and fixing the code will be a tedious task. So, want to know if anyone in the community has faced such situations and want to share their experience on resolving those. ~Thanx Abhijit

2 2

help
by Radekkostra＠seznam.cz 30 Apr '18

30 Apr '18

hello, i am trying to build boost, but i have problems. First is in log(bootstrap.log - could not find "vswhere") and second is when compiling boost(this command :.\b2 --toolset=msvc link=shared,static address -model=64 --with-system --with-filesystem -j 4(5 failed,12skipped,79 updated).

2 2

[Process] Help needed with boost::process::extend::on_*
by Günter Berner 26 Apr '18

26 Apr '18

I am using boost::process::child to create a child process: boost::process::child child("foo"); This works fine so far (on Linux + Windows). Now i want to use a handler which is executed during the fork process: boost::process::child child("foo", boost::process::extend::on_setup = [](auto& exec) { // ... }); This also works fine - as long as a more or less up-to-date C++ compiler or C++ standard. Since g++-4.8.5 (which I have to use) does not support auto template deduction for lambdas, i have to replace the lambda parameter type with a concrete type. boost::process::child child("foo", boost::process::extend::on_setup = [](<WHAT_GOES_HERE?>& exec) { // ... }); Boost.Process documentation only uses the modern approach with auto template deduction. I simply cannot find an example/documentation where the concrete types are shown. Thanks.

1 0

failed coversion
by Markel, Joseph 25 Apr '18

25 Apr '18

Is there a way to get the int value by performing division on boost::any variables? #include <boost/any.hpp> int main(void) { boost::any a = 10; std::cout << boost::any_cast<int>(a) << std::endl; boost::any s = 2.5; // scaling factor // scale the value a = boost::any_cast<int>(a)/boost::any_cast<float>(s); std::cout << boost::any_cast<int>(a) << std::endl; } This throws the error boost::bad_any_cast: failed conversion using boost::any_cast Thanks CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain proprietary and privileged information for the use of the designated recipients named above. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

2 1

[multiprecision] static_cast<cpp_bin_float_100> gives strange values.
by Vögl, Christian 20 Apr '18

20 Apr '18

Hi everyone. The following Situation: I tried to improve the accuracy of a numerical function by replacing all double variables with cpp_bin_float_100. The parameters of this function contain two 3-element double arrays, which I convert to cpp_bin_float_100 by the following function: static void equal(cpp_bin_float_100* a, double* b) { for(int i=0; i<3;i++) { a[i]=static_cast<cpp_bin_float_100>(b[i]); } } the third element seems to be converted correctly, the first and second are totally off. (e. g. 100 -> 1.5625)

2 1

[asio] Using struct ip_mreqn to joing multicast group
by Klebsch, Mario 20 Apr '18

20 Apr '18

Hi, I need to receive multicasts on multiple interfaces and handle them differently, depending on the network interface they arrived on. For each network interface, I create an UDP socket and I use Socket.set_option(boost::asio::ip::multicast::join_group(MCastReqAddr.to_v4(), LocalAddr.to_v4() ), ec); to join the multicast group. LocalAddr is the local IPv4 address of the interface. Unfortunately, I receive each incoming multicast message on each socket. I found, that boost::asio::ip::multicast::join_group uses struct ip_mreq, where the multicast address and the local address can be specified. On linux the man page on IP_ADD_MEMBERSHIP tells to use struct ip_mreqn. This structure had an additional member imr_ifindex. The documentation is not very clear about the difference between imr_address and imr_ifindex. So, I want to try it out and wonder, whether boost::asio supports using struct ip_mreqn for IP_ADD_MEMBERSHIP. If not, does anybody know, how to write my own class to be used with Socket.set_option? 73, Mario -- Mario Klebsch Actia I+ME GmbH Mario.klebsch(a)ime-actia.de<mailto:Mario.klebsch@ime-actia.de> Dresdenstrasse 17/18 Fon: +49 531 38 701 716 38124 Braunschweig Fax: +49 531 38 701 88 Germany

1 0

Boost.Range and initializer_list
by Robert Jones 18 Apr '18

18 Apr '18

Hi All Does the Boost.Range library support initializer_list as a range type? I thought anything with begin() and end() methods was fair game, but this code doesn't work, unless I'm doing it wrong. #include <iostream> #include <vector> #include <boost/range/adaptor/reversed.hpp> int main( ) { using namespace std; using namespace boost::adaptors; vector<int> v { 1, 2, 3 }; for( int i : v | reversed ) { cout << i << " "; } // Ok for( int i : { 1, 2, 3 } | reversed ) { cout << i << " "; } // Bad } Kind Regards Rob.

3 3

[Boost.Range] combine, native range-for, and destructuring
by John M. Dlugosz 18 Apr '18

18 Apr '18

I want to go through two vectors at the same time, and the way to do this is to "zip" the items from each into a tuple. boost::combine is a function for that. for (auto&[def,residue] : boost::combine(playdef, residues)) { gives me an error 1>e:\scratch\c++code\scratchproject2\fizzbuzz\fizzbuzz.cpp(66): error C2440: 'initializing': cannot convert from 'boost::tuples::cons<std::pair<int,std::string_view> &,boost::tuples::cons<int &,boost::fusion::detail::build_tuple_cons<boost::fusion::single_view_iterator<Sequence,boost::mpl::int_<1>>,Last,true>::type>>' to 'boost::tuples::cons<std::pair<int,std::string_view> &,boost::tuples::cons<int &,boost::fusion::detail::build_tuple_cons<boost::fusion::single_view_iterator<Sequence,boost::mpl::int_<1>>,Last,true>::type>> &' The only difference is in the final `&` character. Trying to explore the behavior in pieces, I try: for (auto row : boost::combine(playdef, residues)) { auto&[def, residue] = row; // line 1 row.get<1>() = 17; // line 2 residue= 42; // line 3 Now line2 does work, and I note that assignment goes through and updates the original `residues` vector. The destructuring on line 1 does compile now, being on a separate line. But line 3 gives me an error about not being able to assign to a crazy complicated type. What's going on? Is Boost.Range zipped ranges simply not compatible with the native language features?

4 5

Turning off BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS for MSVC++
by Billy O'Neal (VC LIBS) 17 Apr '18

17 Apr '18

Hi folks! As part of a recent cleanup of some of our iostreams bits I removed a double-seek inside std::filebuf. (Previously, std::filebuf didn't take advantage that we know ::fsetpos just accepts a 64 bit number position) Moreover, in previous releases of MSVC++, that still would have been correct; filebuf was getting to the same place in a very indirect way. I know just casting std::fpos to a streamoff works to get the position going back to at least VS 2015, and it probably works a decade earlier than that (though I have not tested). Shame on us for adding a pretty name to std::fpos not depicted in the standard. Would you accept a patch to $\boost\iostreams\detail\config\fpos.hpp adding this guard before attempting to define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS? !(_MSVC_STL_VERSION >= 141) I submitted a patch to do that here: https://github.com/boostorg/iostreams/pull/57 Thanks folks! Billy O'Neal Visual C++ Libraries

3 2

Boost.Range and result_type
by Robert Jones 17 Apr '18

17 Apr '18

Hi All I have a suspicion this is all ancient history now, but I was surprised this code worked. #include <iostream> #include <vector> #include <boost/range/adaptor/transformed.hpp> struct TimesTwo { // using result_type = int; int operator( )( int i ) const { return i * 2; } }; int main( ) { using namespace std; using namespace boost::adaptors; vector<int> v { 0, 1, 2, 3, 4, 5 }; for( int i : v | transformed( TimesTwo( ) ) ) { cout << i << " "; } cout << endl; } Due to result_type being commented out. Am I right in thinking this is what BOOST_RESULT_OF_USE_DECLTYPE was all about, and everything now just works because modern compilers are implemtenting decltype now? Kind Regards Rob.

2 1

[DateTime] localtime_r() issue
by Latimerius 16 Apr '18

16 Apr '18

Hi, I'm trying to build a project that uses Boost.Log (which in turn uses Date_Time) from Boost 1.65.1 on a platform that uses Clang with (apparently) Dinkumware for a standard library implementation. Compilation fails in date_time/c_time.hpp on line 67 due to a use of undeclared identifier 'localtime_r'. The standard library implementation indeed doesn't seem to have localtime_r(), just localtime_s(). Compilation of the failing code in c_time.hpp is enabled by the preprocessor symbol BOOST_DATE_TIME_HAS_REENTRANT_STD_FUNCTIONS having been #define'd which happens in date_time/compiler_config.hpp based on BOOST_HAS_THREADS being #define'd and a bunch of compiler checks that probably don't get it quite right. Could someone give me some advice how to deal with this? Thanks in advance!

1 0

[release] Boost 1.67.0
by Daniel James 15 Apr '18

15 Apr '18

Release 1.67.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 2 new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <https://www.boost.org/users/news/version_1.67.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.67.0/> To install this release on your system, see <https://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team

3 3

Convert boost::shared_ptr to std::shared_ptr for boost::dll::import
by David Demelier 13 Apr '18

13 Apr '18

Hello, In my application I use std::shared_ptr in the public API for loading plugins. I wanted to use boost::dll to import dynamically plugins as well. It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old. I wanted to convert the boost shared_ptr to std with the following function: std::shared_ptr<plugin> load(boost::shared_ptr<plugin> ptr) { return std::shared_ptr<plugin>(ptr.get(), [ptr] (auto) {}); } It works at perfectly at runtime, however my application segfaults at end, when destroying objects. I suspect that it's because the internal boost::dll shared_library is destroyed **before** my own shared_ptr. The backtrace: (gdb) bt #0 0x00007ffff3f054d8 in ?? () #1 0x00007fffffffdb80 in ?? () #2 0x00007ffff4109400 in ?? () #3 0x00007ffff4add6f8 in _nl_current_default_domain () from /lib64/libc.so.6 #4 0x00007ffff47641d8 in __run_exit_handlers () from /lib64/libc.so.6 #5 0x00007ffff476422a in exit () from /lib64/libc.so.6 #6 0x00007ffff474df31 in __libc_start_main () from /lib64/libc.so.6 #7 0x0000000000413c1a in _start () Is there any chance I can safely convert the smart pointer? Regards, -- David

8 12

Credits to Boost.Asio
by David Demelier 13 Apr '18

13 Apr '18

Hello, I'm the author of irccd [0], a C++ IRC bot extensible with plugins. Up to the 3.0.0 version current in development, I had my network code written by myself (being used of lots of poll(2) usage in C). I have switched to Boost.Asio a while ago to remove my own code and facilitate further development. Even though I think it has its learning curve, I enjoyed a lot the switch and tested my IRC bot to connect 100 times in the same instance to my own local IRC server. It took less than 2 seconds to join all requested channels, taking only 2MB of RAM. This is just awesome. Congratulations for this powerful module :) [0]: http://projects.malikania.fr/irccd -- David

1 0

boost::rational does not maintain its invariant in case of overflow
by Frédéric 11 Apr '18

11 Apr '18

With the program shown below, I obtained the following output: std::numeric_limits<long>::max() == 9223372036854775807 r == boost::rational<long>(4294967296, 1853020188851841) == 4294967296/1853020188851841 r * r == 0/8733086111712066817 Clearly there are 2 overflows but this leads to the invariant of the class not being maintained, i.e. the faction is not simplified to 0/1 (gcd(num, den) != 1). F #include <boost/rational.hpp> #include <iostream> int main() { std::cout << "std::numeric_limits<long>::max() == " << std::numeric_limits<long>::max() << '\n'; boost::rational<long> r(4294967296, 1853020188851841); std::cout << "r == boost::rational<long>(4294967296, 1853020188851841) == " << r << '\n'; std::cout << "r * r == " << (r * r) << '\n'; return 0; }

2 2

How do I "run the configure tests"?
by Chris Stankevitz 10 Apr '18

10 Apr '18

Can't find anything about it in the docs. "Unknown compiler version - please run the configure tests and report the results" [1] Thank you, Chris [1] From https://www.boost.org/doc/libs/1_65_1/boost/config/compiler/visualc.hpp

4 5

Toolset version for Visual Studio 2017 15.6.3
by Chris Stankevitz 10 Apr '18

10 Apr '18

What version should I pass to b2 --toolset=msvc-x.y for "Visual Studio 2017 15.6.3"? [1] says [2] will have an up-to-date list with an answer, but [2] is not up-to-date. Thank you, Chris [1] https://www.boost.org/doc/libs/1_65_1/more/getting_started/windows.html#ide… [2] https://www.boost.org/build/doc/html/bbv2/reference/tools.html

4 4

[asio] SSL async_shutdown() never finishes if called when async_read_some() is in progress
by Alexander D. 08 Apr '18

08 Apr '18

Hello, I'm writing a middleware which basically adds an SSL layer to the connection between a client and a server. The connection is bidirectional, so I need to read from each side and write to the other. The client can also close the connection at any time, in which case async_shutdown() must be called on the server's stream. The problem is, often the shutdown happens when the program is waiting on the server through async_read_some(), and the shutdown will never finish. The following code illustrates this issue: #include <iostream> #include <boost/asio.hpp> #include <boost/asio/ssl.hpp> int main(int argc, char* argv[]) { try { boost::asio::io_context io_context; boost::asio::streambuf buffer; boost::asio::ssl::context ctx(boost::asio::ssl::context::tlsv12); ctx.set_verify_mode(boost::asio::ssl::verify_none); boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sock(io_context, ctx); sock.next_layer().connect(boost::asio::ip::tcp::endpoint( boost::asio::ip::make_address("127.0.0.1"), 4433)); sock.handshake(boost::asio::ssl::stream_base::client); /* "async_shutdown" won't appear unless async_read_some() * is commented out */ sock.async_read_some(buffer.prepare(1024), [](boost::system::error_code, size_t) {std::cout << "async_read_some" << std::endl;}); sock.async_shutdown([](boost::system::error_code) {std::cout << "async_shutdown" << std::endl;}); io_context.run(); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } return 0; } To reproduce, start up an SSL server: openssl genrsa -out key.pem 2048 openssl req -new -sha256 -key key.pem -out csr.csr openssl req -x509 -sha256 -days 365 -key key.pem -in csr.csr -out server.pem openssl s_server -key key.pem -cert server.pem and run the program. Notice that "async_shutdown" does not finish even if the server is killed. In practice, this leaks the memory of the shutdown handler and whatever is bound to it. The only solution I can think of would be to cancel the read operation, but there's no portable way in asio to do this. Can someone point out how to solve this? Cheers, Alexander

5 11

[release] Boost 1.67.0 Beta 1
by Daniel James 07 Apr '18

07 Apr '18

Boost release 1.67.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/> The SHA256 checksums are as follows: 154cf490da858fd9c2307bb904b07a42cbe8355ecf99d5477f0d843c6d03cdda boost_1_67_0_b1.7z 0d854b208fefaeb5837d6c417f505b189275e32d017f6226001fb165a5ac51ed boost_1_67_0_b1.tar.bz2 6eb3f9ca8db355765f41361e1e26976228f0c2dff400aade8a5e97aec6aa59f4 boost_1_67_0_b1.tar.gz 678a6459f2517932536ec97297be1de46ea073f2e2ee17ec8397b80aa0953f49 boost_1_67_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_67_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

9 14

Pointer Container Library changes in 1.66.0
by Kevin Hardman 06 Apr '18

06 Apr '18

I am seeing changes in the Pointer Container Library that are preventing my existing application from compile. I see no notice of changes in the 1.66.0 release notes <http://www.boost.org/users/history/version_1_66_0.html <http://www.boost.org/users/history/version_1_66_0.html>>. Is there documentation on the changes and what is required to migrate existing users to the new library? —kevin

5 10

[log] Unable to use own severity struct encapsulated in namespace
by Sebastian Messerschmidt 06 Apr '18

06 Apr '18

Hi folks, When taking this example [1] and modifying the enum 'severity_level' like this: namespace x { struct test { enum severity_level { normal, notification, warning, error, critical }; }; } and replacing all references to severity_level with the appropriate x::test::severity_level the 'operator<<' overload for the severity_level is not issued. Can anyone help me with this one? I can supply the complete modified example if needed Cheers Sebastian [1] https://www.boost.org/doc/libs/1_58_0/libs/log/example/doc/tutorial_attribu…

2 4

[ptr_map] Warning about returning address of local variable
by Bill Buklis 05 Apr '18

05 Apr '18

I'm not sure if this a potential bug/problem or just a benign warning, but when using the map_values range adaptor with a ptr_map container I get a warning about returning an address of a local variable. It seems benign as the expected processing happens, but this type of warning generally doesn't sound like a good thing. The following useless code will trigger it. #include <boost/ptr_container/ptr_map.hpp> #include <boost/range/algorithm.hpp> #include <boost/range/adaptors.hpp> struct sample { int value; }; typedef boost::ptr_map<int, sample> themap; int main() { themap data; int key = 5; data.insert(key, new sample); boost::for_each(data | boost::adaptors::map_values, [](sample* s) { s->value = 10; }); return 0; } I'm using Visual Studio 2017. I also have conformance mode (/permissive-) turned on for stricter language compliance in case it makes a difference. As an aside, I was a little surprised when trying out this little sample that the inclusion of the above headers is enough to require linking with the boost regex library. I figure it's probably a reference in the adaptors somewhere. It's not a big deal. These lib files are normally available anyway. -- Bill

2 1

boost::asio::async_read_until fills streambuf less than actually received
by David Demelier 03 Apr '18

03 Apr '18

Hello, I'm using Asio to read IRC messages asynchronously from a server. I use boost::asio::async_read_until with "\r\n" as delimiter and a boost::asio::streambuf as output buffer. I mostly implemented the code like described on my original question/answer here: https://stackoverflow.com/questions/40561097/read-until-a-string-delimi ter-in-boostasiostreambuf I sometimes get the bytes_transferred argument bigger that what is filled into the buffer. My code looks like this: void connection::do_recv(handler_t handler) { boost::asio::async_read_until(socket_, buffer_, "\r\n", [this, handler] (auto code, auto xfer) { if (code || xfer == 0U) handler(std::move(code), message()); else { //assert(buffer_.size() > xfer); std::cout << "xfer: " << xfer << std::endl; std::cout << "size: " << buffer_.size() << std::endl; std::string str( boost::asio::buffers_begin(buffer_.data()), boost::asio::buffers_begin(buffer_.data()) + xfer - 2 ); buffer_.consume(xfer); handler(std::move(code), message::parse(str)); } }); } void connection::rflush() { if (input_.empty()) return; do_recv([this] (auto code, auto message) { auto h = input_.front(); // Delete first, in case of exceptions. input_.pop_front(); if (h) h(code, std::move(message)); if (!code) rflush(); }); } void connection::recv(handler_t handler) { auto in_progress = !input_.empty(); input_.push_back(std::move(handler)); if (!in_progress) rflush(); } For some reasons, after several calls, I get an assertion failure in the std::string construction. Because buffer_.size() is actually smaller than xfer. I could not understand why. Example of output: ... ... xfer: 87 size: 141 Note: I've implemented the recv() public function like what I can see for send in some tutorials. I wanted a queue of handlers so I can safely call recv() multiple times before first functions finished completely. Regards, -- David

2 1

Crossbuilding for ARM
by Mats Webjörn/WIKAB 30 Mar '18

30 Mar '18

I'm trying to build for ARM, and have some problems in making b2 find user-config.jam when it's located outside boost root dir. First I go to boost/tools/build and run ./b2 install -prefix=/home/administrator/project/myproj/build/boost Then I run ./b2 toolset=gcc-arm --build-dir=/home/administrator/project/myproj/build/boost stage According to http://www.boost.org/build/doc/html/bbv2/overview/configuration.html Boost.Build<http://www.boost.org/build/doc/html/bbv2/overview/configuration.html%20Boos…> will search $HOME and $BOOST_BUILD_PATH, but if I add --debug-configuration to b2 command then I can see that it searches '/home/administrator' = $HOME '/home/administrator/project/myproj/externals/boost/tools/build/src/kernel' '/usr/share/boost-build' '/home/administrator/project/myproj/externals/boost/tools/build/src/kernel' '/home/administrator/project/myproj/externals/boost/tools/build/src/util' '/home/administrator/project/myproj/externals/boost/tools/build/src/build' '/home/administrator/project/myproj/externals/boost/tools/build/src/tools' '/home/administrator/project/myproj/externals/boost/tools/build/src/contrib' '/home/administrator/project/myproj/externals/boost/tools/build/src/.'. Where none of the directories searched is the one I've provided as buid directory. It seems odd that $BOOST_BUILD_PATH should be "the one in the top-level directory of your Boost.Build installation" since http://www.boost.org/build/doc/html/bbv2/overview/invocation.html describes --build-dir as "the build directories for all project roots being built". It seems like the documentation isn't correct. I'm just not sure which one is right and which is wrong. Has anyone crossbuilt for ARM on Linux? Regards Mats Webjörn E-Mail: konsult(a)webjorn.com Webjörn IngenjörsKonsult AB Tel +46 8 584 238 80 Solhemsbackarna 75A Fax +46 8 445 69 21 SE-163 56 SPÅNGA Mobil +46 70 639 16 99 Sweden

1 0

[Boost::Test] short form of catch_system_errors not working
by Konstantin Kivi 30 Mar '18

30 Mar '18

Occasionally I need a core dump if testing goes wrong. Boost test have the following option ------------ Parameter: catch_system_errors Allows to switch between catching and ignoring system errors (signals). Command line formats: --[no_]catch_system_errors[=<boolean value>] -s[ <boolean value>] ------------------- I never managed to get short options to work and has to search for a long option exact name. Neither '-s no', '-s false' , -sno with or without quotes are not accepted. examples ----- $ test_app -s no Boost.Test WARNING: token "no" does not correspond to the Boost.Test argument and should be placed after all Boost.Test arguments and the -- separator. For example: test_app --random -- no ------ $ test_app "-s no" Invalid separator for the parameter catch_system_errors in the argument -s no ----- Is it a known bug? Best regards, Konstantin

2 1

[boost][interprocess] Need clarification on file_lock documentation
by Rob Conde 29 Mar '18

29 Mar '18

The documentation of boost::interprocess::file_lock has some cautions on synchronization limitations: * It's unspecified if a file_lock synchronizes two threads from the same process. * It's unspecified if a process can use two file_lock objects pointing to the same file. But then gives the guidance: * For each file, use a single file_lock object per process. * Use the same thread to lock and unlock a file. I then created the following example: <https://wandbox.org/permlink/dO2rRDCHVWBE3pGr>https://wandbox.org/permlink/3CNfkA3RcMkwbd2v #include <fstream> #include <iostream> #include <cstdlib> #include <boost/interprocess/sync/file_lock.hpp> #include <boost/interprocess/sync/scoped_lock.hpp> #include <boost/filesystem.hpp> #include <mutex> #include <thread> #include <chrono> int main() { std::ofstream("f.txt"); boost::interprocess::file_lock lock("f.txt"); std::mutex mtx; const size_t max = 100; size_t t1Count = 0; std::thread t1 ( [&lock,&t1Count,&mtx,max]() { while(t1Count < max) { //std::lock_guard<std::mutex> mtxLock(mtx); boost::interprocess::scoped_lock<boost::interprocess::file_lock> guard(lock); std::cout << "Number 1" << std::endl; t1Count++; std::this_thread::sleep_for(std::chrono::milliseconds(1)); } } ); size_t t2Count = 0; std::thread t2 ( [&lock,&t2Count,&mtx,max]() { while(t2Count < max) { //std::lock_guard<std::mutex> mtxLock(mtx); boost::interprocess::scoped_lock<boost::interprocess::file_lock> guard(lock); std::cout << "Number 2" << std::endl; t2Count++; std::this_thread::sleep_for(std::chrono::milliseconds(1)); } } ); t1.join(); t2.join(); return 0; } It only works properly if the std::mutex is used in addition to the file_lock. That was originally my thought when I read "It's unspecified if a file_lock synchronizes two threads from the same process.", but it seemed like I was following the guidance "Use the same thread to lock and unlock a file.". If I haven't messed anything up, I would probably update the documentation to say something like: "If utilitizing the file_lock from multiple threads within the same process, synchronize access to the file_lock with an intraprocess synchronization mechanism such as a mutex." Otherwise, is it a bug? Thanks, Rob

1 0

[beast] Custom, application specific header
by DePizzottri 28 Mar '18

28 Mar '18

Hi, I need to send custom application specific header in the response, but http::response operates only with set of predefined http::field values. Does anyone know how can I set custom field without implementing own `fields` class? Or is there any tips or example how can it be implemented (I know about Fields/FieldsWriter concepts)? -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

2 3

boost::dll in cygwin
by Matthew von Arx 27 Mar '18

27 Mar '18

Has anyone tried using the boost::dll library in cygwin? Boost attempts to load <link.h> which is not applicable to a Cygwin system. Is there any way to #define an option so that the boost::dll library will operate in this mixed windows/linux-like environment? Thanks, -- Matthew von Arx Electromechanical Engineer (C) 678-953-1752

2 1

Boost managed memory files
by Assaf Ben-amitai 26 Mar '18

26 Mar '18

Hi, I'm a user of boost interprocess managed memory file. I'm facing the follwing issue - it seems that if a process fails while allocating memory from a managed file, the internal data-structures may corrupt , making the managed file becomes unuseable. Does anyone have any info on efforts / projects to improve on this situation? Thx, Assaf

1 0

boost::asio blocking socket read with timeout with multiple threads
by tom＠quarendon.net 24 Mar '18

24 Mar '18

I've got a boost::asio based server, and generally it's working well. The server runs multiple threads, each simply running the io_service::run method on the same io_service object. It accepts multiple connections and processes multiple concurrent sockets. It uses a strand per connection to ensure that the data for each connection is processed strictly sequentially. For various reasons it uses a mixture of async and sync reads. The trouble I'm having is implementing a timeout on the synchronous (blocking) reads. I want to protect the server in the case of a client sending an erroneous or malicious packet for example, and make sure a read doesn't block forever. There was a post back in 2007 that gave a technique (https://lists.boost.org/Archives/boost/2007/04/120339.php) There's a stack overflow question that references that (https://stackoverflow.com/questions/13126776/asioread-with-timeout) There are some examples in the docs that perform a similar kind of technique. In the examples, the server is all asynchronous. The client is synchronous, but only uses one thread. The example from 2007 also only uses one thread. The examples all revolve around the technique of starting an *async* read, then performing a nested loop of io_service::run_one. However, so far I've been unable to find a form of code that works reliably in a multithreaded environment. The basis for my experimentation is here: https://gist.github.com/anonymous/1160c11f8ed9c29b9184325191a3a63b It starts a server thread, then starts a client that makes a connection and then writes nothing, to simulate a "bad" client and to provoke a "timeout" condition. What I'm finding is this: With one server thread I can make it work OK. The nested loop of "run_one()" operates correctly. With multiple server threads though, I can't make it work reliably. The basis of the loop is: bool timedOut = false; bool readComplete = false; timer.async_wait(strand_.wrap(boost::bind(&handleReadTimeout, &timedOut, &socket_, _1))); async_read(socket_, buffer(b), strand_.wrap(boost::bind(handleReadComplete, &ec, &bytesRead, &readComplete, &timer, _1, _2))); while (socket_.get_io_service().run_one()) { if (timedOut && readComplete) { break; } } handleReadTimeout sets the timedOut flag to true and calls "cancel" on the socket. The handleReadComplete callback sets readComplete to true and calls cancel on the timer. With multiple threads, the handleReadTimeout/handleReadComplete callbacks are run on other threads. So the while loop here just blocks, as there is never anything to run. That's my surmise of what's going on anyway. I've experimented with strands to try and force it all onto the same thread, but so far failed (if the above code is called in the context of the same strand, it just seems to block the handleReadTimeout and handleReadComplete callbacks from being called). Note that if I expend my example to include other clients talking to a simple "echo" service to simulate other traffic, then the while loop above *does* wake, as that other traffic gives it something to do. But that's fragile. The alternative formulation, the one I started with actually, is to do an async wait on the timer, and a normal synchronous read on the socket. The timer callback performs a cancel (or close -- I tried both) on the socket hoping to cause the socket read to error. This is the kind of thing you'd do if you were programming raw sockets. That works fine on Windows, but won't work on Linux. The documentation for cancel does say it cancels any outstanding *async* calls, but I'm surprised calling close doesn't work and cause the read to wake. So I'm stuck. I was hoping someone here could point me in the right direction, as it seems an obvious thing (to me) to want try and do. Is there a form of code that allows me to perform a synchronous read from a socket and time it out, which will work in a multi threaded/single io service environment? This is all with boost 1.64 by the way. Thanks for any help in advance.

6 27

Re: [Boost-users] boost::asio blocking socket read with timeout with multiple threads
by tom＠quarendon.net 23 Mar '18

23 Mar '18

> You're right. That poll_read loop consumes the alarm :/ > > So then i think the fallback has to be a raw Berkley sockets read against > the native_handle(), with a signal to cause the EINTR. Yes, and I've tried basically that method earlier. It works fine, as long as you don't want to use the SSL wrapper, which is what I ultimately want to do. Of course there, you don't have the control to do that. Well, I could write my own socket class variant and wrap that in the SSL wrapper, but that's daft. You can't "test" the socket by using a poll with a timeout, because there may be unprocessed data that the SSL code has read off the socket that it hasn't returned to you yet, so you'd block when actually there was data to return (been there). There is, as far as I can see, no sensible solution to this. The best I've seen involves mutexes and condition variables, but that's just horrible for what should just consist of passing a timeout value to the poll call. It's just that from the socket class you don't have that control. You DO have that control if you use the basic_socket_streambuf class and wrap the socket in an iostream. That's the odd thing. The functionality IS available in some form, so it's clearly recognised as useful at some level, it's just never been pushed down into the socket itself.

1 0

[boost.test] floating point comparison with user defined type
by Georgios Sermaidis 22 Mar '18

22 Mar '18

Hello, I have created a class to represent the euro currency and I am trying to use boost.test to check if two euro amounts are sufficiently close. I was expecting the following to pass the test given the tolerance level I have set, but instead it fails. What is the proper way to compare two user-defined decimals? Thank you for your time. #define BOOST_TEST_MODULE My Test #include <boost/test/included/unit_test.hpp> class eur { long double m_amount; public: eur(long double amount) : m_amount(amount){} bool operator ==(const eur& rhs) const { return m_amount == rhs.m_amount; } bool operator !=(const eur& rhs) const { return m_amount != rhs.m_amount; } friend std::ostream& operator <<(std::ostream& os, const eur& rhs); }; std::ostream& operator <<(std::ostream& os, const eur& rhs) { os << "EUR " << rhs.m_amount; return os; } BOOST_TEST_DECORATOR(* boost::unit_test::tolerance(eur(0.1))) BOOST_AUTO_TEST_CASE(first_test) { eur x(1.1); eur y(1.2); BOOST_TEST(x == y); }

2 1

boost::units::information::byte_base_unit off by a factor of 8
by Simon Doppler 21 Mar '18

21 Mar '18

I am trying to build a program that will display file sizes in human readable form. The file size is in bytes and I am using boost::units to convert the bytes to a binary prefixed unit. Using the example code found here[1], I build a small program to test the library and the output is off by a factor of 8: boost::units::quantity<boost::units::information::byte_base_unit::unit_type> b = 2048. * boost::units::information::byte_base_unit::unit_type(); std::cout << boost::units::engineering_prefix << b << std::endl; // expected 2.048 kb std::cout << boost::units::symbol_format << boost::units::binary_prefix << b << std::endl; // "expected 2 Kib" but the output on stdout is: 16.384 kb 16 Kib which is 8 times the expected result. The whole example code can be found here[2]. I have tested this code both on Archlinux (boost 1.66.0) as well as Ubuntu Xenial Server (libboost-dev 1.58.0.1ubuntu1). Do you have any idea on how to get the correct output (other than divide the number of bytes by 8 on the input) ? Best regards Simon Doppler [1] http://www.boost.org/doc/libs/1_65_0/doc/html/boost_units/Examples.html#boo… [2] https://dopsi.ch/tmp/main.cpp

2 1

[boost.test] floating point comparison with user defined type
by Georgios Sermaidis 20 Mar '18

20 Mar '18

Apologies, I just found the relevant documentation: http://www.boost.org/doc/libs/1_66_0/libs/test/doc/html/boost_test/testing_… <http://www.boost.org/doc/libs/1_66_0/libs/test/doc/html/boost_test/testing_…>

1 0

[Asio] How to implement a server and client that replies to all clients but one
by Gonzalo Garramuño 20 Mar '18

20 Mar '18

Hi. I want to have a variation on the chat server/client model in that there's a language with instructions being sent. Both the server and the client need to parse this language. When the server changes something, it sends the change in the language to all clients. When the client changes something it sends the change to the server which in turn resends it to all clients but, here's the catch, not to the one that sent the change in the first place. I managed the removal of the client by doing: ParserList::const_iterator i = clients.begin(); ParserList::const_iterator e = clients.end(); for ( ; i != e; ++i ) { try { if ( !(*i)->socket_.is_open() ) continue; std::string p = boost::lexical_cast<std::string>( (*i)->socket_.remote_endpoint() ); if ( p == id ) continue; (*i)->deliver( cmd ); } catch( const std::exception& e ) { LOG_CONN( "Parser::write " << e.what() ); } catch( ... ) { LOG_CONN( "Parser::write unhandled exception" ); } } } I managed to create a working version of the above also by modifying the asio async example using multiple inheritance for the parser (which both the client and the tcp_session inherit). However I am unhappy with this. I ask here to see if someone can suggest a more simple approach to this. -- Gonzalo Garramuño

2 1

[asio] Boost-1.65.0 TlsSlot leak on win32
by Klebsch, Mario 20 Mar '18

20 Mar '18

Hi, I am using boost version 1.65.0 in a 32 bit DLL. I use VS2005 When using ApplicationVerifier, I got application verifier stops due to leaked TLS slots. The TLS slots are allocated in win_tss_ptr_create(). Each slot is wrapped into RAII class win_tss_ptr. The constructor allocates the TLS slot and the destructor de-allocates it. I put printf-Statements in both methods and I see, that the constructor is called twice, while the destructor is not called at all. If I put a breakpoint into the destructor, it never triggers. The printf() satemets show, that the following instances have been constructed: boost::asio::detail::win_tss_ptr<class boost::asio::detail::call_stack<class boost::asio::detail::win_iocp_io_service,struct boost::asio::detail::win_iocp_thread_info>::context>::win_tss_ptr boost::asio::detail::win_tss_ptr<class boost::asio::detail::call_stack<class boost::asio::detail::strand_service::strand_impl,unsigned char>::context>::win_tss_ptr When I put a breakpoint into the constructor, I see, that both instances seem to be global variables > xxx.dll!boost::asio::detail::win_tss_ptr_create() Line 40 C++ xxx.dll!boost::asio::detail::win_tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>::win_tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>() Line 42 + 0x3a bytes C++ xxx.dll!boost::asio::detail::tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>::tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>() + 0xf bytes C++ xxx.dll!`dynamic initializer for 'boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::top_''() Line 165 + 0xd bytes C++ msvcr80d.dll!_initterm(void (void)* * pfbegin=0x101c43a0, void (void)* * pfend=0x101ce9c0) Line 855 C xxx.dll!_CRT_INIT(void * hDllHandle=0x10000000, unsigned long dwReason=0x00000001, void * lpreserved=0x00000000) Line 316 + 0xf bytes C xxx.dll!__DllMainCRTStartup(void * hDllHandle=0x10000000, unsigned long dwReason=0x00000001, void * lpreserved=0x00000000) Line 492 + 0x11 bytes C xxx.dll!_DllMainCRTStartup(void * hDllHandle=0x10000000, unsigned long dwReason=0x00000001, void * lpreserved=0x00000000) Line 462 + 0x11 bytes C Does anyone on this list has an idea, why the destructors aren't called? Thanks in advance, Mario Klebsch -- Mario Klebsch Actia I+ME GmbH Mario.klebsch(a)ime-actia.de<mailto:Mario.klebsch@ime-actia.de> Dresdenstrasse 17/18 Fon: +49 531 38 701 716 38124 Braunschweig Fax: +49 531 38 701 88 Germany

2 2

C++Now 2018 Program Published
by Jon Kalb 19 Mar '18

19 Mar '18

Boosters, The program has (mostly) been published for C++Now 2018: http://cppnow.org/announcements/2018/03/2018-program-announced/ It promises to be an exciting event. It isn’t too late to decide to join us in Aspen this may: http://cppnow.org/registration/ Jon

1 0

singleton.hpp, leak
by Matt Vinson 19 Mar '18

19 Mar '18

Hello,I am using 64-bit, Windows 7, Visual Studio 2017, 15.5.7 on a MFC project. Since updating to 1.66, I think I have leaks traced to singleton.hpp. I put a _crtBreakAlloc = Allocation number and it stops near singleton.hpp.Is it possible this class now has leaks?It true, is there a work around? Any help is appreciated,

2 1

[Asio] How to assign raw sockets (descriptors) to boost::asio::ssl::stream ?
by Dmitriy V 17 Mar '18

17 Mar '18

Hi guys ! I have client server app written on boost::asio. I want to implement updating the server through `execve`. But I don't know how to assign integer socket descriptor (given by streamssl_.lowest_layer().native_handle()) to newly initialized server object after the updating (descriptors strored/restored in shared memory ...) Any help, please ! -- the best regards

2 2

Building Boost 1.66.0 - probable user error
by Larry 16 Mar '18

16 Mar '18

I must be getting old. Building Boost used to be so much easier. I suspect I have missed something in the doc. I downloaded 1.66.0. This is for Win8.1 and MSVC 2017. From a command line bootstrap finally worked to get b2 although there were complaints about some of the options. Running b2 fails. I used to do .\b2 --prefix=xxx toolset=msvc --build-type=complete stage Almost verbatim from the Getting Started doc. stage is not a target is the error. As far as I know the only way to find targets is to wander through .jam files (finding targets was always difficult as far back as 1.27 as I recollect). Any idea what I missed and where? Larry

2 1

[Optional][Variant] Different behavior vs std c++17
by dariomt＠gmail.com 14 Mar '18

14 Mar '18

Hi list, I'm observing different behavior in boost::optional and boost::variant compared to their std c++17 versions. Using Boost 1.64 The following example fails to compile with -DUSE_BOOST using either gcc 7.3 or clang 6.0 #include <boost/optional.hpp> #include <boost/variant/variant.hpp> #include <optional> #include <variant> struct A {}; struct B {}; struct C {}; #ifdef USE_BOOST using V = boost::variant<A,B,C>; using OV = boost::optional<V>; #else using V = std::variant<A,B,C>; using OV = std::optional<V>; #endif OV f(B b) { return b; } Is this difference in behavior expected for such a simple example? Is it possible to improve Boost to make this example compile? Thanks in advance! PS: the Boost only version works in VS2015, not sure why... PPS: Try it in godbolt! https://godbolt.org/g/n4Vbr9 gcc 7.3 says <source>: In function 'OV f(B)': <source>:20:12: error: could not convert 'b' from 'B' to 'OV {aka boost::optional<boost::variant<A, B, C> >}' clang 6.0.0 says <source>:20:12: error: no viable conversion from returned value of type 'B' to function return type 'OV' (aka 'optional<variant<A, B, C> >') return b; ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:796:5: note: candidate constructor not viable: no known conversion from 'B' to 'boost::none_t' for 1st argument optional( none_t none_ ) BOOST_NOEXCEPT : base(none_) {} ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:800:5: note: candidate constructor not viable: no known conversion from 'B' to 'boost::optional<boost::variant<A, B, C> >::argument_type' (aka 'const boost::variant<A, B, C> &') for 1st argument optional ( argument_type val ) : base(val) {} ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:805:5: note: candidate constructor not viable: no known conversion from 'B' to 'boost::optional<boost::variant<A, B, C> >::rval_reference_type' (aka 'boost::variant<A, B, C> &&') for 1st argument optional ( rval_reference_type val ) : base( boost::forward<T>(val) ) ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:877:5: note: candidate constructor not viable: no known conversion from 'B' to 'const boost::optional<boost::variant<A, B, C> > &' for 1st argument optional ( optional const& rhs ) : base( static_cast<base const&>(rhs) ) {} ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:882:2: note: candidate constructor not viable: no known conversion from 'B' to 'boost::optional<boost::variant<A, B, C> > &&' for 1st argument optional ( optional && rhs )

1 0

missing libboost_zlib-vc140-mt-x64-1_66.lib
by Sebastian Pfützner 12 Mar '18

12 Mar '18

Hello, I tried to build boost iostreams with zlib support with the following command on Windows: b2 -j 10 --build-dir=build\x64 --stagedir=stage\x64 --toolset=msvc -sZLIB_SOURCE=L:\vc14\zlib\zlib-1.2.8 runtime-link=shared link=static threading=multi address-model=64 debug release stage But if I try to link my program using iostreams with zlib filter it complains about the missing file libboost_zlib-vc140-mt-x64-1_66.lib, and I see it was not built. I also tried editing the project-config.jam as described in the docs: http://www.boost.org/doc/libs/1_66_0/doc/html/bbv2/reference.html#bbv2.refe… Same result. I also tried to use a pre-built zlib binary. Same result. What should I do? here is the output of b2: - 32-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : no (cached) - junctions supported : yes (cached) - hardlinks supported : yes (cached) - C++11 mutex : yes (cached) - Boost.Config Feature Check: cxx11_auto_declarations : yes (cached) - Boost.Config Feature Check: cxx11_constexpr : yes (cached) - Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached) - Boost.Config Feature Check: cxx11_final : yes (cached) - Boost.Config Feature Check: cxx11_hdr_mutex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_regex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached) - Boost.Config Feature Check: cxx11_lambdas : yes (cached) - Boost.Config Feature Check: cxx11_noexcept : yes (cached) - Boost.Config Feature Check: cxx11_nullptr : yes (cached) - Boost.Config Feature Check: cxx11_rvalue_references : yes (cached) - Boost.Config Feature Check: cxx11_template_aliases : yes (cached) - Boost.Config Feature Check: cxx11_thread_local : yes (cached) - Boost.Config Feature Check: cxx11_variadic_templates : yes (cached) - has_icu builds : no (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes (cached) - bzip2 : no (cached) - lzma : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - native-atomic-int32-supported : yes (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-visibility : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : no (cached) - long double support : yes (cached) warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no (cached) - addr2line builds : no (cached) - WinDbg builds : yes (cached) - WinDbgCached builds : yes (cached) - zlib : yes (cached) - bzip2 : no (cached) - lzma : no (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building

3 8

[Interval] Help debugging compiler optimization
by Tim van Erven 12 Mar '18

12 Mar '18

Dear all, I am trying to understand why I am getting different numerical results with the interval library depending on the optimization level of the compiler. I am attaching the smallest example I have been able to create: # On my Mac laptop Apple LLVM version 9.0.0 (clang-900.0.39.2) boost 1.66 (installed via homebrew) $ g++ foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) $ g++ -O2 foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (1.0000000000000000000000000000000000000000000000000000000000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (1.0000000000000000000000000000000000000000000000000000000000000000,1.0000000000000000000000000000000000000000000000000000000000000000) I would expect to get the same output in both cases, but the lower end-points are different in the second case, and seem wrong to me since third2 * 3.0 < 1.0. # On my Linux machine the effect is different: gcc version 5.4.0 20160609 boost 1.58 on Ubuntu 16.04.9 $ g++ foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) $ g++ -O2 foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (1.0000000000000000000000000000000000000000000000000000000000000000,1.0000000000000000000000000000000000000000000000000000000000000000) Can anyone explain what is going on? Thanks in advance, Tim -- Tim van Erven<tim(a)timvanerven.nl> www.timvanerven.nl

7 14

[Boost.Serialization] (De-)serialization with class versioning
by Lars Ruoff 11 Mar '18

11 Mar '18

Hi, i use the class versioning feature of Boost.Serialization, with an external (non-intrusive) serialization function like this: BOOST_CLASS_VERSION(GAMEINFO, 1) template <typename Archive> void serialize(Archive &ar, GAMEINFO& gameSettings, const unsigned int version) { ar & gameSettings.NPODS; // ... if (version > 0) ar & gameSettings.ARENA_GOAL_EXCLUSION_RADIUS; } Now as soon, as i set BOOST_CLASS_VERSION(GAMEINFO, 1), i get version==1 in this serialize function, even when i *deserialize* (load from archive). I would have expected to get the version of the data in the saved archive in this case. Say i saved with an old version=0. Then my class evolved and i set BOOST_CLASS_VERSION(GAMEINFO, 1). But when reading the old archive, i expect version==0 in the function so i can react on it. Instead, i get always version==1, as soon as i compile with BOOST_CLASS_VERSION(GAMEINFO, 1), even when i'm reading old files! What am i missing? regards, Lars R.

3 7

boost::serialization - Non intrusive serialization of user-defined members?
by Lars Ruoff 05 Mar '18

05 Mar '18

Hi, I have a class structure like class MemberClass; class ContainerClass { MemberClass special_member; int other_members; }; Following the example in http://www.boost.org/doc/libs/1_66_0/libs/serialization/doc/ i want to write a non-intrusive serialization: template<class Archive> void serialize(Archive & ar, ContainerClass & c, const unsigned int version) { ar & c.other_members; // easy - built-in type serialize(ar, c.special_member, version); //use same version??? } Assuming there's is also a non-intrusive void serialize(Archive & ar, MemberClass & m, const unsigned int version); this compiles and works but i feel this is not the way to do it because it reuses the version number of the container class for the member class? So how to handle that? Must the Container class manage version of its members individually? I suggest to add a section "Non-intrusively Serializable Members" to documentation with an example. Cheers, Lars R.

3 7

[fiber] Fiber context switching during stack unwinding...
by Oliver Seiler 01 Mar '18

01 Mar '18

(Hopefully I'm not writing an essay for something that is a gcc/libstdc++/Linux bug) I've been using Boost.Context for a number of years now, to do something similar to what Boost.Fiber does. We recently upgraded our development target environment to Debian 9 (gcc 6.3), and moved up to Boost 1.62.0, so I've been looking at Boost.Fiber to replace how we're using Boost.Context (because it looks like it could greatly simplify our code, among other things). One thing I ran into with Boost.Context was that it interacted in some interesting ways with exception handling, and I haven't really seen any discussion about it. Specifically, switching contexts with an active exception (so during stack unwinding, or in a catch block) would result in weird behaviour in the other context (std::uncaught_exception() returning true, std::current_exception() returning the exception from the other context, try/catches in the new context causing new problems when switching back to the original context which is in the middle of stack unwinding, etc). I chalked that up to limitations of the context switching, though I haven't seen any mention of avoiding context switches with active exceptions; presumably this is some interaction with gcc's exception implementation, and would maybe need support from libunwind to save/restore the exception state (I don't recall if I checked if clang produced similar results, though I'll probably give it a go when I have the chance). So I wasn't surprised when I ran into similar problems with Boost.Fiber. I am wondering why this aspect of usage isn't discussed in any of the documentation; it would be nice if these libraries could work well with language features like exceptions, but I understand that the language spec doesn't really speak to the stack switching happening under-the-hood. It actually wouldn't surprise me that this wasn't even a problem in all environments, and just happens to be an artifact of the Linux implementation, but then we're either talking about unspecified or undefined behaviour, but would be nice to know. Even in the documents going through the C++ standards committee I don't see much mention of how things like coroutines should interact with something like std::current_exception() (perhaps because it is assumed to "just work" and doesn't need additional comment?) Anyone else ever run into issues related to this? Seems like any use of RAII for exception handling would easily run into problems. Mostly I've just found ways to work around it (e.g., not allowing the context switch if std::uncaught_exception() or std::current_exception() indicate it would be unsafe to do so, typically by throwing another exception) but this tends to make libraries harder to use correctly (e.g., can't really allow context switching in a destructor, or in a function called from a destructor, etc). Cheers Oliver

3 4

why boost does not have skip list implementation?
by David Frank 01 Mar '18

01 Mar '18

like java concurrentSkipListSet for example. Thanks, David

1 0

PPA for boost
by legalize+jeeves＠mail.xmission.com 28 Feb '18

28 Feb '18

[Please do not mail me a copy of your followup] Hello fellow boosters, I am one of the maintainers of the C++ language track on exercism.io. When I first implemented this language track, we didn't have good regex support in g++'s standard library yet, so we needed boost.regex to fill that gap. Since we were already going to use boost.regex, I used boost.test for the unit test support. At the time, I found a PPA that was providing prebuilt binaries for ubuntu. Since that time, the need for boost.regex has gone away because the standard library implementation has been completed for g++. Along the way, the biggest source of problems in getting people going with C++ has been boost. For Windows users, it's annoying that CMake won't "just find" boost when you install it because there's no uniform mechanism between boost, packaging and CMake to say where boost got installed. For Mac users, they end up having difficulty with homebrew and fighting with Xcode. For Linux users, the PPA has gone stale and they end up being forced to build from scratch and get sent off into a ditch. In the meantime, we've got conan at stable 1.0 version right now, but that introduces a python dependency and then a conan dependency and for beginners I don't know if that's a path less fraught with peril. We've done some work on a branch to ditch boost.test and therefore boost entirely and switch the unit test framework to Catch. We have yet to "drop the hammer" on that and bring it onto master because reasons. (I am not the developer of that branch, but I suspect it hasn't happened yet because of the other integration issues that are needed; namely a bunch of documentation has to be updated and there will be teething pains with anyone who has already downloaded existing exercises and written them against boost.test.) Now, I find it hard to believe that I am the only one that has suffered from these issues all this time. Sure, if you only use header-only libraries then you don't need to build anything, but there are more than a few libraries in boost that either require or benefit significantly from being compiled. In all this time, have we not managed to come up with a stable, reliable PPA archive with ongoing support for boost for linux users? All I seem able to find are half-heartedly maintained PPAs with stale versions of boost on them. I have even tried to navigate going about setting up my own PPA in order to solve the problem myself, but I found launchpad.net and the whole PPA process so poorly documented and explained that I couldn't make head-nor-tails of it and gave up. (And this is coming from someone who has done more than my fair share of packaging and installer work on multiple platforms.) -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

2 1

Missing libs
by Tim Burgess 28 Feb '18

28 Feb '18

Hi, I downloaded the modular Boost master from Git Hub, as per instructions and built it on Windows as follows: .\Bootstrap .\b2 headers .\b2 This generated (amongst others) the following libs for boost::filesystem: libboost_filesystem-vc141-mt-gd-x32-1_67.lib libboost_filesystem-vc141-mt-gd-x64-1_67.lib libboost_filesystem-vc141-mt-x32-1_67.lib libboost_filesystem-vc141-mt-x64-1_67.lib I then tried to build a static release X64 version of my application using VS2017 and got: 1>LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc141-mt-s-x64-1_67.lib' Obviously, I don't have this file, though I had thought that .\b2 was supposed to build all targets. So, I tried: .\b2 link=static This still does not generate the required file - where am I going wrong, please? BTW, I have checked that my project's library path points to the appropriate boost\stage\lib folder. Best wishes. Tim Burgess

2 2

[Thread] Version 1.66.0 incompatible with ISOLATION_AWARE_ENABLED
by Jim Wilburn 28 Feb '18

28 Feb '18

I work on a Windows code base that I have been updating from Boost 1.64.0 to Boost 1.66.0. One of the projects sets ISOLATION_AWARE_ENABLED to 1 (refer to https://msdn.microsoft.com/en-us/library/windows/desktop/bb773175(v=vs.85).…) #define ISOLATION_AWARE_ENABLED 1 The project also includes <boost/thread.hpp>. The Windows SDK version is 10.0.16299.0. The include chain is: <boost/thread.hpp> <boost/thread/thread.hpp> <boost/thread/thread_only.hpp> <boost/thread/win32/thread_data.hpp> <boost/thread/win32/thread_primitives.hpp> <boost/detail/winapi/dll.hpp> <boost/winapi/dll.hpp> The last include contains constructions such as: BOOST_SYMBOL_IMPORT boost::winapi::HMODULE_ WINAPI LoadLibraryA(boost::winapi::LPCSTR_ lpFileName); With a nonzero ISOLATION_AWARE_ENABLED, this results in redefinition errors, e.g.: .../boost/winapi/dll.hpp(38): error C2375: 'IsolationAwareLoadLibraryA': redefinition; different linkage ...\include\10.0.16299.0\um\winbase.inl(287): note: see declaration of 'IsolationAwareLoadLibraryA' Jim Wilburn

2 1

all roots of a polynomial
by mdebonis 22 Feb '18

22 Feb '18

Hello, I found Boost while searching for a C++ library which can do accurate polynomial root finding. The problem is that the documentation does not make it very clear how to implement this tool. Does anyone by any chance have some sample code on implementing this feature or steer me in the direction of an example in the documentation? I would like to use the best decimal place accuracy (it appears that you can get 50-place here?) Thanks! -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

4 3

Boost improperly including NTVERP.H
by Brian Catlin 22 Feb '18

22 Feb '18

Boost 1.66.0 is causing the Windows file NTVERP.H to be included (defining macros such as VER_DEBUG, VER_PRODUCTVERSION_STR, etc), preventing the definition of those macros by the application. This behavior didn't exist in 1.65.1, and breaks a standard Windows paradigm (it is very common for a Windows program to have a Version.h file containing the version resource macros (that are also defined in NTVERP.H), and then include Version.h in the main CPP file and the Resources.RC file). The NTVERP.H file contains the version information for the Windows SDK, and should NOT be included in an application! NTVERPH.H is included in: boost.1.66.0.0\lib\native\include\boost\predef\platform\windows_uwp.h boost.1.66.0.0\lib\native\include\boost\winapi\config.hpp

1 0

compilation error
by Dk Jack 21 Feb '18

21 Feb '18

Hi, I am getting a compilation error when trying to compile my app. I've detailed my issue on stack overflow. https://stackoverflow.com/questions/48897103/compile- error-in-boost-header-file-fails-on-centos-7-compiles-on-ubuntu-16-04 Would appreciate if someone here can provide some guidance on how to resolve it. Thanks. D.

1 0

Serialization of optional<std::string>
by Chardrazle 21 Feb '18

21 Feb '18

As part of upgrading a product to a later version of boost the compilation has tripped up on serialization of a boost::optional<std::string>. The /optional.hpp/ header now has the comment: ...and this fires for std::string. What, if any, is the recommended way forward for this? An example code snippet to illustrate: Previous version of boost: 1.50; new: 1.6x Compiling with g++ 4.6.4 (although same problem with 4.8.5): -W -Wall -std=c++0x... (The real code is actually using the portable_binary_archive, but let's avoid muddying the waters at this stage :) -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

2 6

Math and numerics: Odeint - problem with adaptive step size
by William Heitler 20 Feb '18

20 Feb '18

Hello, I'm a moderately experienced C++ programmer using Visual Studio 2017, but I'm new to using the boost odeint library. I'm trying to integrate the Hodgkin-Huxley equations, which are a set of ODEs that describe the generation of nerve impulse. The output should be a time-series waveform which is mainly flat but with occasional spikes in it. I have a functor HH which works fine with a standard fixed-step Runge-Kutta routine runge_kutta4< state_type > stepper; integrate_const(stepper, HH, x, 0.0, 20.0, 0.04,trace_observer()); This code produces exactly the right waveform However, I would like to use an adaptive step size because the waveform is pretty flat between the spikes. I tried the following: integrate_adaptive(make_dense_output(1.0e-6, 1.0e-6, runge_kutta_dopri5< state_type >()), hh, x, 0.0, 10.0, 0.04, trace_observer()); This works up to about the peak of the first spike, but then crashes with the error message: Debug Assertion Failed! ... Expression: vector iterator not incrementable It dies in the Visual Studio vector library code _Vector_const_iterator& operator++() in a call from boost::norm_inf where iterator first1 reports as first1 {2.105352686232e-314#DEN} std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<double> > > I certainly don't understand how the boost code works under the hood, but I wondered if anyone could suggest a change in my calling code that might make it work? I have hand-crafted some adaptive step size code which works OK (and does run faster than the fixed step size), but it is a bit of a kludge and I would rather use code developed by people who actually understand the maths. For reasons of brevity I haven't put the HH code in this message, but could do if it would help. Thanks for any help Dr W J Heitler School of Biology University of St Andrews 01334 463490 www.st-andrews.ac.uk/~wjh<http://www.st-andrews.ac.uk/~wjh>

1 0

[Iostreams] Known issue with 32-bit and iostreams::file_descriptor_sink?
by Tim Landscheidt 19 Feb '18

19 Feb '18

Hi, I'm trying to debug several issues in ledger (https://www.ledger-cli.org/) under Fedora 26 (boost 1.63; https://github.com/ledger/ledger/issues/534) and Debian Stretch (boost 1.62; https://github.com/ledger/ledger/issues/539) These issues occur only on 32-bit architectures (i386/i686), and on Fedora 26 (boost 1.63) some segmentation faults can be /fixed/ by executing: | std::ostream *dummy = new iostreams::stream<iostreams::file_descriptor_sink>(2, iostreams::never_close_handle); but this does not "work" on Debian Stretch (boost 1.62). Does that ring a bell for anyone? (NB: I don't want to im- ply that there is a bug in Boost, but maybe someone recog- nizes the scenario and can suggest where the real issues probably lie.) TIA, Tim

1 1

Compiling boost for Intel compiler on Windows
by Boaz Barnea MTH 19 Feb '18

19 Feb '18

Hi, I followed the steps<https://software.intel.com/en-us/articles/building-boost-with-intel-c-compi…> (with adjustments for intel compiler version 18) to build boost using Intel compiler. I have Intel i7 processor, with windows 7 64-bit version, therefore I run compilervars.bat batch with intel64 flag. I run b2 with address-model=32, yet in boost libboost_log-iw-mt-gd-x32-1_66.lib is created as an x64 binary (I see it using 'dumpbin /HEADERS libboost_log-iw-mt-gd-x32-1_66.lib') I guess the library is built by default as x64 for some reason.... any idea? Thanks, Boaz. *********************************************************************************************** Please consider the environment before printing this email ! The information contained in this communication is proprietary to Israel Aerospace Industries Ltd. and/or third parties, may contain confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this communication in error, please notify the sender immediately and delete it from your computer. Thank you. Visit us at: www.iai.co.il

1 0

[Container] flat_multimap::erase crash on OSX 10.13.3/AppleClang Release mode
by Ho Cheung 19 Feb '18

19 Feb '18

Hi all, Please see attached CMakeLists and cpp file for minimal reproducible example. The throw seems to not always trigger (roughly 20-30% failure rate for me). Compiler: hoc$ clang --version Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.4.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin hoc$ system_profiler SPSoftwareDataType | grep Version System Version: macOS 10.13.3 (17D47) Kernel Version: Darwin 17.4.0 -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

2 2

[boost] Yap's formal review is starting now!
by Louis Dionne via Boost 16 Feb '18

16 Feb '18

Dear Boost community, The formal review of Zach Laine's Yap library starts Monday, February 5th and ends on Wednesday, February 14th. Yap is a C++14-and-later library to build expression templates. Yap uses new features introduced in C++14/17 to make the library simpler to use and compile faster than existing solutions, such as the well known Boost.Proto library. The documentation is available here: https://tzlaine.github.io/yap/doc/html/index.html The GitHub repository is available here: https://github.com/tzlaine/yap We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/tzlaine/yap/issues. Regards, Louis Dionne P.S.: I've been having trouble posting to this list. If this ends up being a duplicate post, let's make this one the official one. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

I search information about directory_iterator
by Andy 16 Feb '18

16 Feb '18

I have: #include <boost/filesystem.hpp> namespace fs=boost::filesystem; for (auto& de : fs::directory_iterator("D:\\prog\\alg\\Diff")) { fs::path p = de.path(); auto ext = fs::extension(p); } directory_iterator is object or non-objective method? How can I write something similar, but database iterator. I want get information from mySQL. The simplest way is add everything returning by select to vector of vector of string. But I prefer database iterator. How it write? How is in general directory_iterator as a iterator model?

2 1

We need more mentors for GSoC
by David Bellot 14 Feb '18

14 Feb '18

Hi Boost community, we have already a few mentors, but we need more. If you're interested working with top-level C++ students from all around the world, please contact me and I'll add you to the list of mentors. We need more mentors now ! Best regards, David

1 0

Boost C++ is a mentoring organization for GSoC'18 !
by David Bellot 12 Feb '18

12 Feb '18

We just received this message from Google. It says it all ! *Congratulations! Boost C++ Libraries has been selected as a Google Summer of Code 2018 mentor organization.* This year again, we will be a mentoring organization for the Google Summer of Code. If you want to be a mentor, please contact me right now and register on the Google Summer of Code website too. Best regards, David

1 0

boost serialisation with clang 5.0.1
by avib369 . 12 Feb '18

12 Feb '18

I having a few problems with boost 1.53. I can build boost1.53 with, gcc 4.3-> 7.3, intel 15->17, clang 3.9.1 However with clang 5.0.1 , things go a bit pear shape. I can build boost 1.53/clang 5.0.1 and and my application no problem. However at runtime in crashes in release mode but works ok in debug mode. My early debugging point to serialisation of ptrs is broken in release mode (03) and clang 5.0.1 Has any one else seen this issue in later boost version with clang 5.0.1 ? ta, Avi

1 0

(no subject)
by giridhar 12 Feb '18

12 Feb '18

Hi Boost https://goo.gl/wknrVF Giridhar

5 4

[Graph] const safety in edge_list_impl::edge_iterator
by Hormoz Zarnani 11 Feb '18

11 Feb '18

Hello, I am wondering if there is a particular reason why the == and != operators for edge_list_impl::edge_iterator (defined in boost/graph/edge_list.hpp) are not marked const: // The implementation class for edge_list. template <class G, class EdgeIter, class T, class D> class edge_list_impl { public: ... struct edge_iterator { ... bool operator==(const self& x) { return _iter == x._iter; } bool operator!=(const self& x) { return _iter != x._iter; } EdgeIter _iter; edge_id _i; }; ... }; Also, it does not seem correct to have different const qualifiers for the operands of these operators (the above effectively says that the right operand is const, but the left operand may be changed). Thanks, Hormoz

1 0

[Interprocess] Message queue hex names
by Davies, John 09 Feb '18

09 Feb '18

I have a handful of processes all communicating with message queues. Infrequently, if a process crashes and restarts, it can't connect to the previously created message queue and creates a new one with a long hex name. This is under Windows, but I'm seeing indications the same thing is happening under Linux. Or something very similar. Under what circumstances does it do this and if I can't stop it, can I at least detect that it happened? ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

1 0

coroutine2: pull/push_type ctors with r-value ref arg
by MM 09 Feb '18

09 Feb '18

Hello, push_type class have this ctor: template< typename Fn > push_type( Fn && fn) that moves the object fn, leaving it in a moved-from state. I have a vector V1<C> of class C instances that expose a public member operator: void operator()( coroutine::pull_type& source ); and I would like to construct a vector V2 of push_types, of same size, each element of V2 I construct by emplacing back a element from V1. I assume that leaves the objects in vector V1 in a moved-from state and not usable. Those objects C in V1 are needed for other purposes. Can I use those instances of C by accessing them where they've been moved to inside the elements of V2? If not, should I make a copy of V1 before populating V2? Thanks,

1 0

Mailman upgrade
by Sys Admin - Boost 08 Feb '18

08 Feb '18

All, Per https://bugs.launchpad.net/mailman/+bug/1747209, Ciere staff will install 2.1.26 beginning 9-Feb-2018 04:00 UTC. While the maintenance is performed, incoming messages to the mailing lists for Boost will be temporarily blocked. This may result in “temporarily unable to deliver” messages received by senders if a message is delivered during the upgrade. The upgrade is expected to finish by 9-Feb-2018 05:00 UTC. Thanks, Brad Johnson Your Friendly Mailing List Admin

1 0

[test] data driven test fails to compile when number of samples greater than 9
by Georgios Sermaidis 08 Feb '18

08 Feb '18

Hello, I am having trouble compiling a simple data driven test with 10 samples. I am using clang++ (Apple LLVM version 9.0.0 (clang-900.0.39.2))with C++14 flags enabled. According to this help page http://www.boost.org/doc/libs/1_66_0/libs/test/doc/html/boost_test/utf_refe… <http://www.boost.org/doc/libs/1_66_0/libs/test/doc/html/boost_test/utf_refe…> my compiler should have no problem dealing with number of samples greater than BOOST_TEST_DATASET_MAX_ARITY which is 10 by default. Even defining BOOST_TEST_DATASET_MAX_ARITY to 20 prior to including any headers still fails to compile with the following error: /usr/local/include/boost/test/data/test_case.hpp:182: error: no matching function for call to 'bind' boost::bind( &TestCase::template test_method<Arg...>, ^~~~~~~~~~~ Any ideas how to fix it? Here is the code: #define BOOST_TEST_MODULE dataset_example68 #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> #include <boost/test/data/test_case.hpp> #include <boost/test/data/monomorphic.hpp> #include <sstream> namespace bdata = boost::unit_test::data; BOOST_DATA_TEST_CASE( test1, bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ) ^ bdata::make( { 1, 2, 3, 5 } ), sample1, sample2, sample3, sample4, sample5, sample6, sample7, sample8, sample9, sample10) {} Thank you!

2 1

[log] Setting log format with string
by Dirk Van Haerenborgh 07 Feb '18

07 Feb '18

Hi, I'm trying to simply set the log format of the sinks using a string. For example from a config file or just in code. Take for instance this simple line taken from the basic_example (https://github.com/boostorg/log/blob/master/example/basic_usage/ main.cpp) logging::add_console_log(std::clog, keywords::format = "%TimeStamp%: %Message%"); Whenever I add %Timestamp% to the log format, I keep getting this error: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::gregorian::bad_year> >' what(): Year is out of valid range: 1400..10000 I can easily reproduce this by running these examples (without modification): https://github.com/boostorg/log/blob/master/example/basic_usage/ main.cpp https://github.com/boostorg/log/blob/master/example/ settings_file/main.cpp Am I doing something wrong? I have this same behaviour on both boost1.62 and boost1.65. The former as installed from the debian package manager. The latter was manually compiled... -Dirk

1 0

[intrusive] list compatibility with existing application-defined intrusive lists
by Rahul Ramadas 04 Feb '18

04 Feb '18

Hi all, boost::intrusive lists can be easily customized to be compatible with an existing doubly-linked intrusive list implementation, such as the one used in the linux kernel (struct list_head). Indeed, I have been able to declare and use a boost::intrusive::list of my own with custom traits that uses struct list_head as the underlying representation, enabling me to simply use .end().pointed_node() to get access to the list head and pass it to legacy C code that expects a struct list_head*. However, I can't think of a way to achieve interoperability in the opposite direction. For example, I have an existing function (to be precise, a callback that I pass to legacy C code), that accepts a struct list_head* that is expected to contain a list of elements of a certain type. I want some way to "wrap" this raw pointer in a type-safe intrusive list type that I use as naturally as a boost::intrusive::list (iteration, modification, etc.). I see no way to achieve this. The way I see it, what I need is a boost::intrusive::list_ptr, a container that doesn't actually own the list head, but rather, points to a list head stored elsewhere. It would have the same interface as a list, allowing me to push_back, clear, etc., but behaves as a pointer when it comes to moves and copies. Additionally, there should also be a boost::intrusive::const_list_ptr, which will not allow me to modify the list, but still allows iteration and other non-modifying operations. Unless, of course, there are already existing mechanisms to achieve this. If anyone has any ideas, please let me know. Thanks.

3 2

Boost Python with Continuum Anaconda?
by Stephen Gray 02 Feb '18

02 Feb '18

I'm trying to get started with Boost Python. I've built the Boost Python libraries and linked a simple test programme with embedded Python. My Python environments are managed by Anaconda. There are errors at runtime as detailed in this Stackoverflow posting: https://stackoverflow.com/questions/48552092/boost-python-embedding-error Can anyone please help me understand what the issue is and how to solve it? With thanks.

1 0

asio: cancelling a named pipe client
by Stian Zeljko Vrba 01 Feb '18

01 Feb '18

I have a client which connects to a named pipe as follows: CreateFile(pipeName.c_str(),GENERIC_READ | GENERIC_WRITE, 0, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, nullptr); The result of this call is assigned to a stream_handle. I want that io service shuts down orderly by run() returning due to running out of work. To achieve this, I post a lambda that effectively calls cancel() on the handle (hidden inside Kill()): _io.post([this]() { for (auto& w : _workers) w->Kill(); }); However, cancel() has no effect: the callback for async_read continues to return with error code of zero and data read from the pipe. For reference, this is the read call with its handler: template<typename T> void read(T& ioh, const asio::mutable_buffer& buf) { ioh.async_read_some(asio::buffer(buf), [this, self = shared_from_this()](const boost::system::error_code& ec, size_t sz) { if (ec == boost::system::errc::operation_canceled) return; if (ec) QUINE_THROW(Error(self->_ownersId, ec, "async_read_some")); self->ReadCompleted(sz); }); } ReadCompleted() processes the received data and loops by calling read() again. If I call close() the callback gets an error code and everything works out correctly, *except* that I get an error code [invalid handle] that gets logged as an error (though it's not). Am I correct in assuming that cancel() is an apparent noop in this case because of the race-condition where an I/O request completes successfully before cancel is invoked? If so, can you suggest a more elegant way (i.e., a way that doesn't induce a hard error) of exiting a loop as described here? Setting a member variable instead of calling cancel? Given the existence of the race-condition, what are use-cases for cancel? How to use it correctly, if at all possible? -- Stian

4 16

Using Boost 1.66 with VS2017
by Tim Burgess 01 Feb '18

01 Feb '18

Hi, I'm getting the following message during compilation of my application: 1>Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message. I don't want to suppress the message, but would appreciate any mods I need to do to actually stop its cause. Many thanks in advance for any suggestions. Best wishes. Tim Burgess

4 8

process/detail/config.hpp
by Nelson, Erik - 2 30 Jan '18

30 Jan '18

I'm upgrading to 1.66 from 1.55 and running into this problem on VS2013 https://svn.boost.org/trac10/ticket/13146 I didn't find anything as I poked about the net- does anyone on the list have any suggestions? ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

1 0

Re: [Boost-users] boost's cmake error on windows platform
by Mefteh Safa 24 Jan '18

24 Jan '18

please help me to fix this problem as soon as possible thanks a lot 2018-01-23 16:10 GMT+01:00 Mefteh Safa <mefteh.safa9(a)gmail.com>: > Hi, > I want to use boost c++ libraries on windows platform with CLion via > cmakelists. I've followed these steps: > 1- download > > boost_1_66_0.7z > <https://dl.bintray.com/boostorg/release/1.66.0/source/boost_1_66_0.7z> > 2- navigate to C:\Program Files\boost_1_66_0\tools\build and Run bootstrap.bat > gcc > 3- Run b2 install --prefix="C:\Program Files\boost-build" > 4- C:\Program Files\boost-build\bin to Windows PATH. > 5- restart my computer > 6- open cmd, then navigate to C:\Program Files\boost_1_66_0 > 7- Run b2 --build-dir="C:\Program Files\boost_1_66_0\build" > --prefix="C:\Program Files\boost" --toolset=gcc install > > here you find the output file containing include directories and libraries: > > boost.7z > <https://drive.google.com/file/d/1bxJqqUgXYvyGnp0g_Mqr259cushpSW78/view?usp=…> > > 8- here the cmakelists.txt file for the configuration of boost. > > but the cmake still show me this problem > [image: Images intégrées 1] > >

2 1

Build Boost 1 66
by Matt Vinson 24 Jan '18

24 Jan '18

In response to this:I can't reproduce your problem. Are there any build errors? Which libraries exactly are missing? In Christ, Steven Watanabe =========================================Thanks for response.Here is my build output (b2 -j%cores% toolset=%msvcver% address-model=64 architecture=x86 link=static threading=multi runtime-link=static --build-type=complete stage --stagedir=stage/x64 > std_out.txt):Performing configuration checks - 32-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : no (cached) - junctions supported : yes (cached) - hardlinks supported : yes (cached) - C++11 mutex : yes (cached) - Boost.Config Feature Check: cxx11_auto_declarations : yes (cached) - Boost.Config Feature Check: cxx11_constexpr : yes (cached) - Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached) - Boost.Config Feature Check: cxx11_final : yes (cached) - Boost.Config Feature Check: cxx11_hdr_mutex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_regex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached) - Boost.Config Feature Check: cxx11_lambdas : yes (cached) - Boost.Config Feature Check: cxx11_noexcept : yes (cached) - Boost.Config Feature Check: cxx11_nullptr : yes (cached) - Boost.Config Feature Check: cxx11_rvalue_references : yes (cached) - Boost.Config Feature Check: cxx11_template_aliases : yes (cached) - Boost.Config Feature Check: cxx11_thread_local : yes (cached) - Boost.Config Feature Check: cxx11_variadic_templates : yes (cached) - has_icu builds : no (cached)warning: Graph library does not contain MPI-based parallel components.note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no (cached) - bzip2 : no (cached) - lzma : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - native-atomic-int32-supported : yes (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-visibility : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : no (cached) - long double support : yes (cached)warning: skipping optional Message Passing Interface (MPI) library.note: to enable MPI support, add "using mpi ;" to user-config.jam.note: to suppress this message, pass "--without-mpi" to bjam.note: otherwise, you can safely ignore this message.warning: No python installation configured and autoconfigurationnote: failed. See http://www.boost.org/libs/python/doc/building.htmlnote: for configuration instructions or pass --without-python tonote: suppress this message and silently skip all Boost.Python targets - libbacktrace builds : no (cached) - addr2line builds : no (cached) - WinDbg builds : yes (cached) - WinDbgCached builds : yes (cached) - zlib : no (cached) - bzip2 : no (cached) - lzma : no (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ...patience......patience......patience......patience......patience......found 17673 targets......updating 1061 targets...compile-c-c++ bin.v2\libs\atomic\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\lockpool.objlockpool.cppmsvc.archive bin.v2\libs\atomic\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_atomic-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_atomic-vc141-mt-sgd-x64-1_66.libbin.v2\libs\atomic\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_atomic-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\system\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\error_code.objerror_code.cppcompile-c-c++ bin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\dlmalloc.objdlmalloc.cppcompile-c-c++ bin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\global_resource.objglobal_resource.cppmsvc.archive bin.v2\libs\system\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_system-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\monotonic_buffer_resource.objmonotonic_buffer_resource.cppcommon.copy stage\x64\lib\libboost_system-vc141-mt-sgd-x64-1_66.libbin.v2\libs\system\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_system-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\pool_resource.objpool_resource.cppcompile-c-c++ bin.v2\libs\chrono\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\chrono.objchrono.cppcompile-c-c++ bin.v2\libs\chrono\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\thread_clock.objthread_clock.cppcompile-c-c++ bin.v2\libs\chrono\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\process_cpu_clocks.objprocess_cpu_clocks.cppcompile-c-c++ bin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\synchronized_pool_resource.objsynchronized_pool_resource.cppcompile-c-c++ bin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\unsynchronized_pool_resource.objunsynchronized_pool_resource.cppcompile-c-c++ bin.v2\libs\thread\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\tss_dll.objtss_dll.cppmsvc.archive bin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_container-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_container-vc141-mt-sgd-x64-1_66.libbin.v2\libs\container\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_container-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.msvc.archive bin.v2\libs\chrono\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_chrono-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\coroutine\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\detail\coroutine_context.objcoroutine_context.cppWarning: Boost.Coroutine is now deprecated. Please switch to Boost.Coroutine2. To disable this warning message, define BOOST_COROUTINES_NO_DEPRECATION_WARNING.compile-c-c++ bin.v2\libs\thread\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\tss_pe.objtss_pe.cppcommon.copy stage\x64\lib\libboost_chrono-vc141-mt-sgd-x64-1_66.libbin.v2\libs\chrono\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_chrono-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\thread\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\future.objfuture.cppcompile-c-c++ bin.v2\libs\context\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\stack_traits.objstack_traits.cppcompile-c-c++ bin.v2\libs\coroutine\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\exceptions.objexceptions.cppWarning: Boost.Coroutine is now deprecated. Please switch to Boost.Coroutine2. To disable this warning message, define BOOST_COROUTINES_NO_DEPRECATION_WARNING.msvc.archive bin.v2\libs\context\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_context-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\exception\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\clone_current_exception_non_intrusive.objclone_current_exception_non_intrusive.cppcommon.copy stage\x64\lib\libboost_context-vc141-mt-sgd-x64-1_66.libbin.v2\libs\context\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_context-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\date_time\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\gregorian\date_generators.objdate_generators.cppmsvc.archive bin.v2\libs\exception\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_exception-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_exception-vc141-mt-sgd-x64-1_66.libbin.v2\libs\exception\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_exception-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\date_time\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\gregorian\greg_weekday.objgreg_weekday.cppcompile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\codecvt_error_category.objcodecvt_error_category.cppcompile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\path_traits.objpath_traits.cppcompile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\utf8_codecvt_facet.objutf8_codecvt_facet.cppcompile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\portability.objportability.cppcompile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\operations.objoperations.cppcompile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\path.objpath.cppcompile-c-c++ bin.v2\libs\thread\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\thread.objthread.cppmsvc.archive bin.v2\libs\thread\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_thread-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\date_time\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\gregorian\greg_month.objgreg_month.cppcompile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\unique_path.objunique_path.cpplibs\filesystem\src\unique_path.cpp(114): warning C4267: 'argument': conversion from 'size_t' to 'DWORD', possible loss of datacommon.copy stage\x64\lib\libboost_thread-vc141-mt-sgd-x64-1_66.libbin.v2\libs\thread\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_thread-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\coroutine\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\stack_traits.objstack_traits.cppWarning: Boost.Coroutine is now deprecated. Please switch to Boost.Coroutine2. To disable this warning message, define BOOST_COROUTINES_NO_DEPRECATION_WARNING.msvc.archive bin.v2\libs\date_time\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_date_time-vc141-mt-sgd-x64-1_66.libmsvc.archive bin.v2\libs\coroutine\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_coroutine-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_coroutine-vc141-mt-sgd-x64-1_66.libbin.v2\libs\coroutine\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_coroutine-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.common.copy stage\x64\lib\libboost_date_time-vc141-mt-sgd-x64-1_66.libbin.v2\libs\date_time\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_date_time-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows_file_codecvt.objwindows_file_codecvt.cpplibs\filesystem\src\windows_file_codecvt.cpp(43): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datalibs\filesystem\src\windows_file_codecvt.cpp(63): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datacompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\numa\windows\pin_thread.objpin_thread.cppmsvc.archive bin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_filesystem-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_filesystem-vc141-mt-sgd-x64-1_66.libbin.v2\libs\filesystem\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_filesystem-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\numa\windows\topology.objtopology.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\algo\algorithm.objalgorithm.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\algo\round_robin.objround_robin.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\algo\shared_work.objshared_work.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\barrier.objbarrier.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\algo\work_stealing.objwork_stealing.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\condition_variable.objcondition_variable.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\algo\numa\work_stealing.objwork_stealing.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\context.objcontext.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\future.objfuture.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fiber.objfiber.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\c_regex_traits.objc_regex_traits.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\properties.objproperties.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\recursive_mutex.objrecursive_mutex.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\mutex.objmutex.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\recursive_timed_mutex.objrecursive_timed_mutex.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\icu.objicu.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cpp_regex_traits.objcpp_regex_traits.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\timed_mutex.objtimed_mutex.cppcompile-c-c++ bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\scheduler.objscheduler.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\regex_debug.objregex_debug.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\regex_raw_buffer.objregex_raw_buffer.cppmsvc.archive bin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_fiber-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_fiber-vc141-mt-sgd-x64-1_66.libbin.v2\libs\fiber\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_fiber-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fileiter.objfileiter.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\regex.objregex.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\static_mutex.objstatic_mutex.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\regex_traits_defaults.objregex_traits_defaults.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\posix_api.objposix_api.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cregex.objcregex.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\instances.objinstances.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\wc_regex_traits.objwc_regex_traits.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\w32_regex_traits.objw32_regex_traits.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\wide_posix_api.objwide_posix_api.cppcompile-c-c++ bin.v2\libs\iostreams\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\file_descriptor.objfile_descriptor.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\encoding\codepage.objcodepage.cppc:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(129): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(139): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(139): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(152): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(155): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(415): warning C4244: 'argument': conversion from '__int64' to 'unsigned int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(406): note: while compiling class template member function 'std::string boost::locale::conv::impl::wconv_from_utf<CharType,2>::convert(const CharType *,const CharType *)' with [ CharType=wchar_t ]libs\locale\src\encoding\codepage.cpp(106): note: see reference to class template instantiation 'boost::locale::conv::impl::wconv_from_utf<CharType,2>' being compiled with [ CharType=wchar_t ]libs\locale\src\encoding\codepage.cpp(161): note: see reference to function template instantiation 'std::string boost::locale::conv::impl::convert_from<wchar_t>(const CharType *,const CharType *,const char *,boost::locale::conv::method_type)' being compiled with [ CharType=wchar_t ]c:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\encoding\wconv_codepage.ipp(424): warning C4244: 'argument': conversion from '__int64' to 'unsigned int', possible loss of datacompile-c-c++ bin.v2\libs\iostreams\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\mapped_file.objmapped_file.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\winstances.objwinstances.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\shared\format.objformat.cppmsvc.archive bin.v2\libs\iostreams\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_iostreams-vc141-mt-sgd-x64-1_66.lib...on 100th target...common.copy stage\x64\lib\libboost_iostreams-vc141-mt-sgd-x64-1_66.libbin.v2\libs\iostreams\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_iostreams-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\shared\formatting.objformatting.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\shared\date_time.objdate_time.cppcompile-c-c++ bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\usinstances.objusinstances.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\shared\ids.objids.cppmsvc.archive bin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_regex-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\util\codecvt_converter.objcodecvt_converter.cppC:\Users\Valued Customer\Documents\Visual Studio 2017\Libraries\boost_1_66_0\boost/locale/generic_codecvt.hpp(232): warning C4244: 'return': conversion from '__int64' to 'int', possible loss of dataC:\Users\Valued Customer\Documents\Visual Studio 2017\Libraries\boost_1_66_0\boost/locale/generic_codecvt.hpp(202): note: while compiling class template member function 'int boost::locale::generic_codecvt<CharType,boost::locale::util::simple_codecvt<CharType>,2>::do_length(mbstate_t &,const char *,const char *,::size_t) const' with [ CharType=wchar_t ]libs\locale\src\util\codecvt_converter.cpp(189): note: see reference to class template instantiation 'boost::locale::generic_codecvt<CharType,boost::locale::util::simple_codecvt<CharType>,2>' being compiled with [ CharType=wchar_t ]libs\locale\src\util\codecvt_converter.cpp(398): note: see reference to class template instantiation 'boost::locale::util::simple_codecvt<wchar_t>' being compiledcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\shared\generator.objgenerator.cppcommon.copy stage\x64\lib\libboost_regex-vc141-mt-sgd-x64-1_66.libbin.v2\libs\regex\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_regex-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\shared\localization_backend.objlocalization_backend.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\util\info.objinfo.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\util\locale_data.objlocale_data.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\std\codecvt.objcodecvt.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\std\collate.objcollate.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\util\default_locale.objdefault_locale.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\shared\message.objmessage.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\std\converter.objconverter.cppcompile-c-c++ bin.v2\libs\graph\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\read_graphviz_new.objread_graphviz_new.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\std\numeric.objnumeric.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\util\gregorian.objgregorian.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\collate.objcollate.cppc:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(149): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(170): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(245): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(249): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datacompile-c-c++ bin.v2\libs\graph\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\graphml.objgraphml.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\converter.objconverter.cppc:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(149): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(170): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(245): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(249): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datacompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\std\std_backend.objstd_backend.cppmsvc.archive bin.v2\libs\graph\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_graph-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_graph-vc141-mt-sgd-x64-1_66.libbin.v2\libs\graph\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_graph-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\lcid.objlcid.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\win_backend.objwin_backend.cppc:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(149): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(170): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(245): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(249): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datacompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\attribute_set.objattribute_set.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\code_conversion.objcode_conversion.cppcompile-c-c++ bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\win32\numeric.objnumeric.cppc:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(149): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(153): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(170): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(245): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datac:\users\valued customer\documents\visual studio 2017\libraries\boost_1_66_0\libs\locale\src\win32\api.hpp(249): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of datacompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\attribute_name.objattribute_name.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\attribute_value_set.objattribute_value_set.cppmsvc.archive bin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_locale-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_locale-vc141-mt-sgd-x64-1_66.libbin.v2\libs\locale\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_locale-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\process_id.objprocess_id.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\named_scope.objnamed_scope.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\process_name.objprocess_name.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\global_logger_storage.objglobal_logger_storage.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\severity_level.objseverity_level.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\thread_id.objthread_id.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\default_attribute_names.objdefault_attribute_names.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\timer.objtimer.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\exceptions.objexceptions.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\once_block.objonce_block.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\text_ostream_backend.objtext_ostream_backend.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\record_ostream.objrecord_ostream.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\thread_specific.objthread_specific.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\core.objcore.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\timestamp.objtimestamp.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\text_multifile_backend.objtext_multifile_backend.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\threadsafe_queue.objthreadsafe_queue.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\event.objevent.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\unhandled_exception_count.objunhandled_exception_count.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\default_sink.objdefault_sink.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\trivial.objtrivial.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\dump_avx2.objdump_avx2.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\dump.objdump.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\dump_ssse3.objdump_ssse3.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\permissions.objpermissions.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\spirit_encoding.objspirit_encoding.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\debug_output_backend.objdebug_output_backend.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\text_file_backend.objtext_file_backend.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\date_time_format_parser.objdate_time_format_parser.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\light_rw_mutex.objlight_rw_mutex.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\ipc_reliable_message_queue.objipc_reliable_message_queue.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\named_scope_format_parser.objnamed_scope_format_parser.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\ipc_sync_wrappers.objipc_sync_wrappers.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\syslog_backend.objsyslog_backend.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\format_parser.objformat_parser.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\mapped_shared_memory.objmapped_shared_memory.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\object_name.objobject_name.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\parser_utils.objparser_utils.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\init_from_stream.objinit_from_stream.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\windows\event_log_backend.objevent_log_backend.cppmsvc.archive bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_log-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_log-vc141-mt-sgd-x64-1_66.libbin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_log-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\matches_relation_factory.objmatches_relation_factory.cppcompile-c-c++-pch bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\pch.pchpch.pch.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\settings_parser.objsettings_parser.cppcompile-c-c++ bin.v2\libs\math\config\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\has_long_double_support.objhas_long_double_support.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\assoc_laguerre.objassoc_laguerre.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\assoc_legendre.objassoc_legendre.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\beta.objbeta.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_1.objcomp_ellint_1.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_2.objcomp_ellint_2.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\filter_parser.objfilter_parser.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_3.objcomp_ellint_3.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_i.objcyl_bessel_i.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\default_formatter_factory.objdefault_formatter_factory.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_k.objcyl_bessel_k.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_j.objcyl_bessel_j.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\formatter_parser.objformatter_parser.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_1.objellint_1.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_neumann.objcyl_neumann.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_2.objellint_2.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_3.objellint_3.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\expint.objexpint.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\laguerre.objlaguerre.cpp...on 200th target...compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\hermite.objhermite.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\legendre.objlegendre.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\default_filter_factory.objdefault_filter_factory.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_legendre.objsph_legendre.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\assoc_laguerref.objassoc_laguerref.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_bessel.objsph_bessel.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\riemann_zeta.objriemann_zeta.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_neumann.objsph_neumann.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\betaf.objbetaf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\assoc_legendref.objassoc_legendref.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_2f.objcomp_ellint_2f.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_1f.objcomp_ellint_1f.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_3f.objcomp_ellint_3f.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_jf.objcyl_bessel_jf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_1f.objellint_1f.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_kf.objcyl_bessel_kf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_neumannf.objcyl_neumannf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_2f.objellint_2f.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_3f.objellint_3f.cppcompile-c-c++ bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\setup\init_from_settings.objinit_from_settings.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\hermitef.objhermitef.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_if.objcyl_bessel_if.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\legendref.objlegendref.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\laguerref.objlaguerref.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\expintf.objexpintf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\riemann_zetaf.objriemann_zetaf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_besself.objsph_besself.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_legendref.objsph_legendref.cppmsvc.archive bin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_log_setup-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\assoc_laguerrel.objassoc_laguerrel.cppmsvc.archive bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_tr1-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\betal.objbetal.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_neumannf.objsph_neumannf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\assoc_legendrel.objassoc_legendrel.cppcommon.copy stage\x64\lib\libboost_math_tr1-vc141-mt-sgd-x64-1_66.libbin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_tr1-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_1l.objcomp_ellint_1l.cppcommon.copy stage\x64\lib\libboost_log_setup-vc141-mt-sgd-x64-1_66.libbin.v2\libs\log\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_log_setup-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_2l.objcomp_ellint_2l.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\comp_ellint_3l.objcomp_ellint_3l.cppmsvc.archive bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_tr1f-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_il.objcyl_bessel_il.cppcommon.copy stage\x64\lib\libboost_math_tr1f-vc141-mt-sgd-x64-1_66.libbin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_tr1f-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_kl.objcyl_bessel_kl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_bessel_jl.objcyl_bessel_jl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_1l.objellint_1l.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cyl_neumannl.objcyl_neumannl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_3l.objellint_3l.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\laguerrel.objlaguerrel.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\ellint_2l.objellint_2l.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\expintl.objexpintl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\hermitel.objhermitel.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\legendrel.objlegendrel.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\riemann_zetal.objriemann_zetal.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_legendrel.objsph_legendrel.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_bessell.objsph_bessell.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\acosh.objacosh.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\sph_neumannl.objsph_neumannl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\asinh.objasinh.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\atanh.objatanh.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\copysign.objcopysign.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\erfc.objerfc.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\erf.objerf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\expm1.objexpm1.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fmax.objfmax.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fmin.objfmin.cppmsvc.archive bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_tr1l-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fpclassify.objfpclassify.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\hypot.objhypot.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\llround.objllround.cppcommon.copy stage\x64\lib\libboost_math_tr1l-vc141-mt-sgd-x64-1_66.libbin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_tr1l-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cbrt.objcbrt.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\log1p.objlog1p.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\lgamma.objlgamma.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\lround.objlround.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\nextafter.objnextafter.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\round.objround.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\nexttoward.objnexttoward.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\trunc.objtrunc.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\tgamma.objtgamma.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\asinhf.objasinhf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\acoshf.objacoshf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\atanhf.objatanhf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\copysignf.objcopysignf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\erfcf.objerfcf.cppmsvc.archive bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_c99-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\erff.objerff.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\expm1f.objexpm1f.cppcommon.copy stage\x64\lib\libboost_math_c99-vc141-mt-sgd-x64-1_66.libbin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_c99-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fmaxf.objfmaxf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fpclassifyf.objfpclassifyf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fminf.objfminf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\lgammaf.objlgammaf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\hypotf.objhypotf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\log1pf.objlog1pf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\llroundf.objllroundf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\lroundf.objlroundf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cbrtf.objcbrtf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\roundf.objroundf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\nextafterf.objnextafterf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\nexttowardf.objnexttowardf.cpp...on 300th target...compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\truncf.objtruncf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\tgammaf.objtgammaf.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\acoshl.objacoshl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\asinhl.objasinhl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\atanhl.objatanhl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\copysignl.objcopysignl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\erfcl.objerfcl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\erfl.objerfl.cppmsvc.archive bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_c99f-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fmaxl.objfmaxl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fpclassifyl.objfpclassifyl.cppcommon.copy stage\x64\lib\libboost_math_c99f-vc141-mt-sgd-x64-1_66.libbin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_c99f-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\expm1l.objexpm1l.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\hypotl.objhypotl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\lgammal.objlgammal.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\llroundl.objllroundl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\log1pl.objlog1pl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cbrtl.objcbrtl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\lroundl.objlroundl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\nextafterl.objnextafterl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\nexttowardl.objnexttowardl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\roundl.objroundl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\fminl.objfminl.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\tgammal.objtgammal.cppcompile-c-c++ bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\truncl.objtruncl.cppmsvc.archive bin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_c99l-vc141-mt-sgd-x64-1_66.libcommon.copy stage\x64\lib\libboost_math_c99l-vc141-mt-sgd-x64-1_66.libbin.v2\libs\math\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_math_c99l-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\positional_options.objpositional_options.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\utf8_codecvt_facet.objutf8_codecvt_facet.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\config_file.objconfig_file.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\convert.objconvert.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\cmdline.objcmdline.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\options_description.objoptions_description.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\variables_map.objvariables_map.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\parsers.objparsers.cppcompile-c-c++ bin.v2\libs\random\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\random_device.objrandom_device.cppcompile-c-c++ bin.v2\libs\serialization\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\basic_archive.objbasic_archive.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\value_semantic.objvalue_semantic.cppmsvc.archive bin.v2\libs\random\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_random-vc141-mt-sgd-x64-1_66.libcompile-c-c++ bin.v2\libs\serialization\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\basic_iserializer.objbasic_iserializer.cppcommon.copy stage\x64\lib\libboost_random-vc141-mt-sgd-x64-1_66.libbin.v2\libs\random\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_random-vc141-mt-sgd-x64-1_66.lib 1 file(s) copied.compile-c-c++ bin.v2\libs\serialization\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\basic_oserializer.objbasic_oserializer.cppcompile-c-c++ bin.v2\libs\serialization\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\basic_pointer_iserializer.objbasic_pointer_iserializer.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\winmain.objwinmain.cppcompile-c-c++ bin.v2\libs\serialization\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\basic_pointer_oserializer.objbasic_pointer_oserializer.cppcompile-c-c++ bin.v2\libs\serialization\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\basic_serializer_map.objbasic_serializer_map.cppcompile-c-c++ bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\split.objsplit.cpp================================================================================================================\Here is a message in console: http://www.boost.org/build/doc/html/index.htmlfailed to write output file 'bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_program_options-vc141-mt-sgd-x64-1_66.lib.rsp'!================================================================================================================Here are the built libraries: Volume in drive C has no label. Volume Serial Number is DC32-C7DD Directory of C:\Users\Valued Customer\Documents\Visual Studio 2017\Libraries\boost_1_66_0\stage\x64\lib 01/24/2018 06:37 AM <DIR> .01/24/2018 06:37 AM <DIR> ..01/24/2018 06:37 AM 0 c.txt01/24/2018 06:19 AM 70,996 libboost_atomic-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 1,956,114 libboost_chrono-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 2,029,624 libboost_container-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 349,880 libboost_context-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 2,610,038 libboost_coroutine-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 3,122,476 libboost_date_time-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 34,236 libboost_exception-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 30,572,974 libboost_fiber-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 6,239,250 libboost_filesystem-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 19,061,424 libboost_graph-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 1,962,594 libboost_iostreams-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 31,815,270 libboost_locale-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 78,533,348 libboost_log-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 79,055,980 libboost_log_setup-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 3,769,638 libboost_math_c99-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 3,610,482 libboost_math_c99f-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 3,726,546 libboost_math_c99l-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 21,521,570 libboost_math_tr1-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 21,565,816 libboost_math_tr1f-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 21,280,044 libboost_math_tr1l-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:20 AM 660,442 libboost_random-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 49,632,980 libboost_regex-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:10 AM 37,608,940 libboost_serialization-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:10 AM 326,972 libboost_stacktrace_noop-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:10 AM 1,048,648 libboost_stacktrace_windbg-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 678,190 libboost_system-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:19 AM 4,237,894 libboost_thread-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:10 AM 1,498,068 libboost_timer-vc141-mt-sgd-x64-1_66.lib01/24/2018 06:10 AM 27,178,304 libboost_wserialization-vc141-mt-sgd-x64-1_66.lib 30 File(s) 455,758,738 bytes 2 Dir(s) 9,402,617,856 bytes free===============================================================================Way back in the build output, under Performing configuration checks, should one of the checks show x64 bit?================================================================================I am using Visual Studio 15.5.4. I had to modify C:\Users\Valued Customer\Documents\Visual Studio 2017\Libraries\boost_1_66_0\boost\config\compiler to clear this warning: Info: Boost.Config is older than your compiler version I changed/added _MSC_VER > 1920================================================================================ Any help is appreciated...

2 1

[boost][asio] Waiting on a returned value run in another strand
by Brian Bartman 24 Jan '18

24 Jan '18

Hello, I'm trying to preform an asynchronous operation in order to obtain a connection from a pool of available connections. I'm trying to leverage strands for two reasons, 1) I don't need locks because I can guarantee that the connection pool access is limited to quick sequential access, and 2) I may need to wait for connections to become available, or I may need to actually make a connection. I'm working with the 1.66 version of boost and I have been searching the internet for ANY answer to this question, so far none of the examples which I've located work any more. All of them simply fail to compile. For example, http://coliru.stacked-crooked.com/a/7427ec669bf0e326 This uses an older version of boost. So how can I do this under the newest version of boost.asio? Any help would be greatly appreciated. -- thanks, Brian Bartman. PhD

2 2

[test] Use-after-free with --log_sink=file, reported by gcc 7.2
by Avi Kivity 23 Jan '18

23 Jan '18

When static destructors are called, as the program exits, we destroy boost::unit_test::(anonymous namespace)::s_log_impl()::the_inst. This has a member vector, m_log_formatter_data. When destroying the second member, we run an ios_base_all_saver destructor, which attempts to restore a stream's format, however that stream has already been deallocated. Maybe that stream is in another static destructor, which was not ordered wrt. this one? Or maybe it was destroyed even earlier, when unit_test_main() exited. From ASan log, it loofs like the former. One static destructor is run from /usr/include/boost/test/impl/framework.ipp:459, while the other is run from /unit_test_log.ipp:122, so there is no ordering abong them. *** No errors detected ================================================================= ==1745==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000016a8 at pc 0x0000015f8892 bp 0x7ffecdb0b720 sp 0x7ffecdb0b710 READ of size 8 at 0x6160000016a8 thread T0 #0 0x15f8891 in std::ios_base::width(long) /usr/include/c++/7/bits/ios_base.h:723 #1 0x161dea0 in boost::io::ios_base_all_saver::restore() /usr/include/boost/io/ios_state.hpp:340 #2 0x161dda6 in boost::io::ios_base_all_saver::~ios_base_all_saver() /usr/include/boost/io/ios_state.hpp:336 #3 0x168a22e in void boost::checked_delete<boost::io::ios_base_all_saver>(boost::io::ios_base_all_saver*) /usr/include/boost/core/checked_delete.hpp:34 #4 0x171b7c5 in boost::detail::sp_counted_impl_p<boost::io::ios_base_all_saver>::dispose() /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78 #5 0x58b2c4 in boost::detail::sp_counted_base::release() /usr/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:109 #6 0x58b51e in boost::detail::shared_count::~shared_count() /usr/include/boost/smart_ptr/detail/shared_count.hpp:419 #7 0x161eadc in boost::shared_ptr<boost::io::ios_base_all_saver>::~shared_ptr() /usr/include/boost/smart_ptr/shared_ptr.hpp:337 #8 0x1589a8a in ~unit_test_log_data_helper_impl /usr/include/boost/test/impl/unit_test_log.ipp:87 #9 0x15f0891 in _Destroy<boost::unit_test::(anonymous namespace)::unit_test_log_data_helper_impl> /usr/include/c++/7/bits/stl_construct.h:98 #10 0x15eb8ad in __destroy<boost::unit_test::(anonymous namespace)::unit_test_log_data_helper_impl*> /usr/include/c++/7/bits/stl_construct.h:108 #11 0x15e32c7 in _Destroy<boost::unit_test::(anonymous namespace)::unit_test_log_data_helper_impl*> /usr/include/c++/7/bits/stl_construct.h:137 #12 0x15cd317 in _Destroy<boost::unit_test::(anonymous namespace)::unit_test_log_data_helper_impl*, boost::unit_test::(anonymous namespace)::unit_test_log_data_helper_impl> /usr/include/c++/7/bits/stl_construct.h:206 #13 0x15c0de2 in ~vector /usr/include/c++/7/bits/stl_vector.h:434 #14 0x158aa72 in ~unit_test_log_impl /usr/include/boost/test/impl/unit_test_log.ipp:122 #15 0x7f6c2db90b57 in __run_exit_handlers (/lib64/libc.so.6+0x3bb57) #16 0x7f6c2db90ba9 in exit (/lib64/libc.so.6+0x3bba9) #17 0x7f6c2db76010 in __libc_start_main (/lib64/libc.so.6+0x21010) #18 0x4172e9 in _start (/home/avi/seastar/build/debug/tests/memcached/test_ascii_parser_g+0x4172e9) 0x6160000016a8 is located 296 bytes inside of 544-byte region [0x616000001580,0x6160000017a0) freed by thread T0 here: #0 0x7f6c32c9d6d8 in operator delete(void*, unsigned long) (/lib64/libasan.so.4+0xe16d8) #1 0x1717f1e in boost::detail::sp_counted_impl_pd<std::basic_ofstream<char, std::char_traits<char> >*, boost::detail::sp_ms_deleter<std::basic_ofstream<char, std::char_traits<char> > > >::~sp_counted_impl_pd() /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:127 #2 0xc1563b in boost::detail::sp_counted_base::destroy() /usr/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:89 #3 0x58b3e4 in boost::detail::sp_counted_base::weak_release() /usr/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:123 #4 0x58b2f3 in boost::detail::sp_counted_base::release() /usr/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:110 #5 0x58b51e in boost::detail::shared_count::~shared_count() /usr/include/boost/smart_ptr/detail/shared_count.hpp:419 #6 0x15fe350 in boost::shared_ptr<std::basic_ofstream<char, std::char_traits<char> > >::~shared_ptr() /usr/include/boost/smart_ptr/shared_ptr.hpp:337 #7 0x160f9ec in boost::unit_test::runtime_config::stream_holder::~stream_holder() /usr/include/boost/test/unit_test_parameters.hpp:96 #8 0x16fb8fc in std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder>::~pair() /usr/include/c++/7/bits/stl_pair.h:198 #9 0x16fb964 in void __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > >::destroy<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >(std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder>*) /usr/include/c++/7/ext/new_allocator.h:140 #10 0x16ef009 in void std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > > >::destroy<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >(std::allocator<std::_Rb_tree_node<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > >&, std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder>*) /usr/include/c++/7/bits/alloc_traits.h:487 #11 0x16d81bc in std::_Rb_tree<boost::unit_test::output_format, std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder>, std::_Select1st<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >, std::less<boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > >::_M_destroy_node(std::_Rb_tree_node<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >*) /usr/include/c++/7/bits/stl_tree.h:650 #12 0x16adac7 in std::_Rb_tree<boost::unit_test::output_format, std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder>, std::_Select1st<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >, std::less<boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > >::_M_drop_node(std::_Rb_tree_node<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >*) /usr/include/c++/7/bits/stl_tree.h:658 #13 0x167e5af in std::_Rb_tree<boost::unit_test::output_format, std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder>, std::_Select1st<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >, std::less<boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > >::_M_erase(std::_Rb_tree_node<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >*) /usr/include/c++/7/bits/stl_tree.h:1858 #14 0x1649760 in std::_Rb_tree<boost::unit_test::output_format, std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder>, std::_Select1st<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> >, std::less<boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > >::~_Rb_tree() /usr/include/c++/7/bits/stl_tree.h:949 #15 0x160f988 in std::map<boost::unit_test::output_format, boost::unit_test::runtime_config::stream_holder, std::less<boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::output_format const, boost::unit_test::runtime_config::stream_holder> > >::~map() /usr/include/c++/7/bits/stl_map.h:294 #16 0x161009b in boost::unit_test::framework::state::~state() /usr/include/boost/test/impl/framework.ipp:459 #17 0x7f6c2db90b57 in __run_exit_handlers (/lib64/libc.so.6+0x3bb57) previously allocated by thread T0 here: #0 0x7f6c32c9c158 in operator new(unsigned long) (/lib64/libasan.so.4+0xe0158) #1 0x169dfd6 in boost::detail::shared_count::shared_count<std::basic_ofstream<char, std::char_traits<char> >*, boost::detail::sp_ms_deleter<std::basic_ofstream<char, std::char_traits<char> > > >(std::basic_ofstream<char, std::char_traits<char> >*, boost::detail::sp_inplace_tag<boost::detail::sp_ms_deleter<std::basic_ofstream<char, std::char_traits<char> > > >) /usr/include/boost/smart_ptr/detail/shared_count.hpp:206 #2 0x16728db in boost::shared_ptr<std::basic_ofstream<char, std::char_traits<char> > >::shared_ptr<std::basic_ofstream<char, std::char_traits<char> >, boost::detail::sp_inplace_tag<boost::detail::sp_ms_deleter<std::basic_ofstream<char, std::char_traits<char> > > > >(std::basic_ofstream<char, std::char_traits<char> >*, boost::detail::sp_inplace_tag<boost::detail::sp_ms_deleter<std::basic_ofstream<char, std::char_traits<char> > > >) /usr/include/boost/smart_ptr/shared_ptr.hpp:372 #3 0x163c6e6 in boost::detail::sp_if_not_array<std::basic_ofstream<char, std::char_traits<char> > >::type boost::make_shared<std::basic_ofstream<char, std::char_traits<char> >>() /usr/include/boost/smart_ptr/make_shared_object.hpp:250 #4 0x15fe6ad in boost::unit_test::runtime_config::stream_holder::setup(boost::unit_test::basic_cstring<char const> const&) /usr/include/boost/test/unit_test_parameters.hpp:114 #5 0x155cd45 in boost::unit_test::framework::impl::setup_loggers() /usr/include/boost/test/impl/framework.ipp:861 #6 0x1561113 in boost::unit_test::framework::init(bool (*)(), int, char**) /usr/include/boost/test/impl/framework.ipp:1033 #7 0x1599d40 in boost::unit_test::unit_test_main(bool (*)(), int, char**) /usr/include/boost/test/impl/unit_test_main.ipp:189 #8 0x15c067f in main tests/test-utils.cc:84 #9 0x7f6c2db76009 in __libc_start_main (/lib64/libc.so.6+0x21009) SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/c++/7/bits/ios_base.h:723 in std::ios_base::width(long) Shadow bytes around the buggy address: 0x0c2c7fff8280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c7fff8290: 00 00 00 00 06 fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff82a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff82b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2c7fff82c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x0c2c7fff82d0: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd 0x0c2c7fff82e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2c7fff82f0: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff8300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c7fff8310: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2c7fff8320: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==1745==ABORTING

2 5

Build Boost 1 66
by Matt Vinson 22 Jan '18

22 Jan '18

Hello - I've been building boost with a script* (via https://studiofreya.com/2017/04/23/building-boost-1-64-with-visual-studio-2…) My Visual C++ project is a static lib so link and runtime-link are static.It's worked for several past build releases. Now with build 1_66, not all x64 libraries are built. There is 74 libraries in the win32 directory and only 27 in the x64. I locate the script using "x64 Native Tools Command Propt for VS2017" I am using Windows7. Any advice is appreciated.Matt *@echo offrem Directory to boost rootset boost_dir=boost_1_66_0 rem Number of cores to use when building boostset cores=%NUMBER_OF_PROCESSORS% rem What toolset to use when building boost. rem Visual Studio 2012 -> set msvcver=msvc-11.0rem Visual Studio 2013 -> set msvcver=msvc-12.0rem Visual Studio 2015 -> set msvcver=msvc-14.0rem Visual Studio 2017 -> set msvcver=msvc-14.1 set msvcver=msvc-14.1 rem Start building boostecho Building %boost_dir% with %cores% cores using toolset %msvcver%. cd %boost_dir%call bootstrap.bat rem Static librariesb2 -j%cores% toolset=%msvcver% address-model=64 architecture=x86 link=static threading=multi runtime-link=static --build-type=complete stage --stagedir=stage/x64 b2 -j%cores% toolset=%msvcver% address-model=32 architecture=x86 link=static threading=multi runtime-link=static --build-type=complete stage --stagedir=stage/win32 pause

2 1

Compiling Boost Libraries
by Good Guy 22 Jan '18

22 Jan '18

How do you guys compile Boost libraries in your project when all the header files are linked using angle brackets? For example in Visual Studio and C++ builder (Embarcadero) a link such as: #include <boost/config.hpp> won't compile but a link such as: #include "boost/config.hpp" Has no problems. How are we suppose to change the files so that there is no such problems. I would like to use only a few libraries in certain projects but changing the files is going to take a heck of a ling time bearing in my mind some files contains nested headers!! Am I missing something here. Surely there must a be a solution because these libraries have been going on since 1999!!

3 3

Boost sync_queue clear
by kjw 21 Jan '18

21 Jan '18

2 2

Question regarding boost binary serializer which is eating 90GB of memory, while re-reading the same content.
by dinesh kumar 21 Jan '18

21 Jan '18

Hi All, Greetings for the day. I am trying to understand the behavior of Boost's binary serializer(Boost version 1.65). Please consider the below example, where I am inserting one record into the file, and trying to read the same record 5 times. #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/serialization/string.hpp> #include <fstream> #include <iostream> using namespace std; using namespace boost::archive; class logEntry { private: size_t m_txID; string m_jsonStr; friend class boost::serialization::access; template <typename Archive> friend void serialize( Archive &ar, logEntry &l, const unsigned int version ); public: logEntry() { m_txID = 0; m_jsonStr = ""; } logEntry( size_t id, const string &val ) { m_txID = id; m_jsonStr = val; } string getJsonValue() { return m_jsonStr; } size_t getTxId() { return m_txID; } }; template <typename Archive> void serialize( Archive &ar, logEntry &l, const unsigned int version ) { ar &l.m_txID; ar &l.m_jsonStr; } size_t prevReadPos = 0; void save( size_t n ) { ofstream file{"/tmp/test.bin", ios::binary | ios::trunc}; binary_oarchive oa{file}; // Save n records for ( int i = 0; i < n; i++ ) oa << logEntry( i, "{Some Json String}" ); file.flush(); file.close(); } // Load data batch wise void load( size_t bsize ) { ifstream file{"/tmp/test.bin", ios::binary}; binary_iarchive ia{file}; // Record file length size_t fileEnd; size_t beg = file.tellg(); file.seekg( 0, ios::end ); fileEnd = file.tellg(); file.seekg( beg, ios::beg ); logEntry l; for ( size_t i = 0; i < bsize; i++ ) { * ia >> l;* * // Reset the file read position to the beginning of the file to read the same line one more time* * file.seekg( beg, ios::beg );* } prevReadPos = file.tellg(); file.close(); } int main() { // Saving only one record save( 1 ); while ( 1 ) { // Trying to read the same record 5 times load( 5 ); sleep( 5 ); } } >From the above code, I am able to read the record one time and whenever I re-set the file pointer back to the beginning of the file, the program "Crashes with SIGKILL". And also, I observed that this process it consumed around *90GB *of memory(I got this reading from xCode while debugging the code). My dev environment is as below. clang --version Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin15.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Kindly let me know if you need any more information from my side. -- Regards, Dinesh manojadinesh.blogspot.com

2 2

Google Summer of Code with Boost
by David Bellot 20 Jan '18

20 Jan '18

Hi everyone, still a few days before we submit our proposal to Google. Don't loose the chance to become a mentor for Boost. It shines on your CV, it is a great opportunity to work with brilliant students around the world, it makes you an official C++ world-wide expert. So far, we have a nice but little list of proposals here: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 It would be good to have a bit more before I go and submit to Google. This will increase our chances to be selected again this year. For Boost it's a great funding worth several thousand of dollars every year. We just don't want to miss it. Best regards, David

1 0

Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)
by Mathieu Peyréga 12 Jan '18

12 Jan '18

Hello, i'm using boost asio 1.66 serial port on a Ubuntu Mate 64 machine, and I facing the fact that open("port name", error_code) command on an already openned port do not return an error. My test sequence : On the same machine I pre-open /dev/ttsS0 on minicom : minicom -D /dev/ttyS0 and check that is indeed open by sending some chars. Now while minicom still openned, I try openning a second minicom on same /dev/ttyS0 and this return an error : "device /dev/ttyS0 locked" as expected. So the device and system is able to knows that ttyS0 is already open (minicom + OS is capable of doing that) Now, with first minicom still running, if I run my program which is doing open("/dev/ttySO",ec), ec is 0 and further is-open() returns true while obviously the port is not openned. When device not already openned with minicom, my software is behaving properly. Am I doing something wrong detecting if the "open" operation suceeded ? I have a separated boost::thread io_thread(boost::bind(&C_IO_Controller::run,&theIOController)); that is running the boost::asio::io_service object the open command is called from the main thread (not the io_thread ) Regards Mathieu

3 3

Debugging into .ipp files
by Abhishek Deshpande 12 Jan '18

12 Jan '18

Hello boost users and gurus, I built boost 1.56 and client code both with -g option. When I try to debug the code, the TUI mode in GDB just wont let me navigate inside the .ipp files of boost libraries. This is a real hassle and as a work around, I generated a preprocessed output file from gcc option -E and renamed it as New.cpp file. This renamed New.cpp will have all of the template instantiations (the ones I was trying to navigate in .ipp file) of a particular boost library (e.g. serialization) embedded in it. I then compiled this New.cpp using -g and debugged it to see some miracle. But it still just doesn't navigate to places (template instantiations that are embedded inside New.cpp) . As such I am in dire need to find a way to debug these .ipp files. I hope I have made my intent clear over here. How do I debug into .ipp files using gdb ? Thanks, AD

1 0