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

[boost.test] Don't report skipped test as failure
by Florian Lindner 11 Jul '16

11 Jul '16

Hello, I use boost.test precondition in an MPI application to disable test at ranks != 0 if they do not use MPI: boost::test_tools::assertion_result isMaster(boost::unit_test::test_unit_id) { return precice::utils::Parallel::getProcessRank() == 0; } BOOST_AUTO_TEST_SUITE(NearestNeighborMapping) BOOST_AUTO_TEST_CASE(ConsistentNonIncremental, * boost::unit_test::precondition(isMaster)) {...} That works perfect, I just don't like that sipped test are reported as errors. Example with all tests deactivated: % ./testprecice Global setup Running 2 test cases... Global teardown *** Errors were detected in the test module "Master Test Suite"; see standard output for details Here you think it's an error, but it's just skipped tests: % ./testprecice -r detailed Global setup Running 2 test cases... Global teardown Test module "Master Test Suite" has failed with: 2 test cases out of 2 skipped Test suite "NearestNeighborMapping" has failed with: 2 test cases out of 2 skipped Test case "NearestNeighborMapping/ConsistentNonIncremental" was skipped Test case "NearestNeighborMapping/ConservativeNonIncremental" was skipped Could this behavior be changed somehow and skipped test not be reported as failures? Thanks, Florian

2 2

substantial lag time difference from boost::thread 1.57 and 1.60
by David Medine 09 Jul '16

09 Jul '16

Hello, I am an engineer in a neurosciences lab. We have some data acquisition software that uses boost::thread and some other boost libraries as well. Part of my job is to measure the lag time for our devices' data acquisition. I have been testing the acquisition software when linking against boost v.1.57.0 and v.160.0. Basically I generate a test signal and read it in with an NIDAQ and our EEG system. The signal is a series of 3ms long pulses. When the input to the NIDAQ goes high, I generate a timestamped marker. Meanwhile the EEG system is getting the same pulse train input and I record that digital data on its own thread and timestamp that as well. Then I compare the timestamps at which the EEG signal has a rising edge with the timestamps of the markers. The difference between these time values is the lag of the EEG system. The app I use to get the EEG signal uses boost::thread. The lag time is consistently ~2.7 ms when linking against boost v.1.57.0 and is a whopping 11.6 ms when I link against v.1.60.0. Since the data acquisition happens in a tight loop on its own thread, I am guessing that there is some kind of increased latency of boost threads in newer versions of the library. Does anybody know what might be causing this? I am on Windows 7, 64-bit and am using the pre-compiled boost libraries (i.e. I am not compiling them myself). Cheers, David

2 2

Acquiring and rebuilding C++ libraries on Windows
by Eric Mittelette 08 Jul '16

08 Jul '16

Hello I'm Program Manager at Microsoft, working on VC++ Libraries team (VC runtime, STL...) We are working on the spec of a tool to acquire 3rd party libraries on Windows. We are targeting mainly OSS libraries, our tool will help dev to rebuild locally from the source code on Windows. Today we have a proto, based on a port tree approach. (having a repo with the build script and the associated patch file) I wanted to have a discussion with the Boost community about this project, and how dev could acquire Boost this way. Feel free to contact me to initiate this discussion, we'll be happy to share our idea and prototype with you and collect feedback and suggestions. Best, Eric Mittelette Senior Program Manager - Visual C++ (VCLib) Microsoft Corp.

6 10

the performance of boost::lock_free is slow in centos 6 and 7
by gao1738＠sina.com 08 Jul '16

08 Jul '16

Hi all, I try the boost::lockfree::queue and find some performance issue： I use the following test programs: lock_free_test.cc #include <boost/thread/thread.hpp> #include <boost/lockfree/queue.hpp> #include <iostream> #include<cstdio> #include <boost/atomic.hpp> boost::atomic_int producer_count(0); boost::atomic_int consumer_count(0); boost::lockfree::queue<int> queue(128); const int iterations = 1000000; const int producer_thread_count = 4; const int consumer_thread_count = 4; void producer(void) { for (int i = 0; i != iterations; ++i) { int value = ++producer_count; while (!queue.push(value)) ; } } boost::atomic<bool> done (false); void consumer(void) { int value; while (!done) { while (queue.pop(value)) ++consumer_count; } while (queue.pop(value)) ++consumer_count; } int main(int argc, char* argv[]) { using namespace std; cout << "boost::lockfree::queue is "; if (!queue.is_lock_free()) cout << "not "; cout << "lockfree" << endl; boost::thread_group producer_threads, consumer_threads;//线程组 for (int i = 0; i != producer_thread_count; ++i) producer_threads.create_thread(producer); for (int i = 0; i != consumer_thread_count; ++i) consumer_threads.create_thread(consumer); producer_threads.join_all(); done = true; consumer_threads.join_all(); cout << "produced " << producer_count << " objects." << endl; cout << "consumed " << consumer_count << " objects." << endl; } locktest.cc #include <boost/thread/thread.hpp> #include <boost/lockfree/queue.hpp> #include <iostream> #include<cstdio> #include <queue> #include <boost/atomic.hpp> using namespace std; boost::mutex producer_count_mu; boost::mutex consumer_count_mu; int producer_count = 0; int consumer_count = 0; std::queue<int> message_queue; boost::mutex queue_mutex; const int iterations = 1000000; const int producer_thread_count = 4; const int consumer_thread_count = 4; void producer(void) { for (int i = 0; i != iterations; ++i) { queue_mutex.lock(); int value = ++producer_count; message_queue.push(value); queue_mutex.unlock(); } } bool done (false); void consumer(void) { int value; while (!done) { queue_mutex.lock(); while (!message_queue.empty()) { message_queue.pop(); ++consumer_count; } queue_mutex.unlock(); } queue_mutex.lock(); while (!message_queue.empty()) { message_queue.pop(); ++consumer_count; } queue_mutex.unlock(); } int main(int argc, char* argv[]) { using namespace std; cout << "boost::lockfree::queue is "; // if (!queue.is_lock_free()) cout << "not "; cout << "lockfree" << endl; boost::thread_group producer_threads, consumer_threads;//线程组 for (int i = 0; i != producer_thread_count; ++i) producer_threads.create_thread(producer); for (int i = 0; i != consumer_thread_count; ++i) consumer_threads.create_thread(consumer); producer_threads.join_all(); done = true; consumer_threads.join_all(); cout << "produced " << producer_count << " objects." << endl; cout << "consumed " << consumer_count << " objects." << endl; } The compile command is: g++ -I/usr/local/inlcude -L/usr/local/lib lock_free_test.cc -lboost_thread -lboost_system -o lock_free_test g++ -I/usr/local/inlcude -L/usr/local/lib lock_test.cc -lboost_thread -lboost_system -o lock_test 1. I first test in on my work computer, which use ubuntu 14.04 with 2core(i5), with boost version: 1.54 gcc version: 4.8.4 g++ version: 4.8.4 The test result is that: time ./lock_test boost::lockfree::queue is not lockfree produced 4000000 objects. consumed 4000000 objects. real 0m3.844s user 0m1.800s sys 0m12.308s time ./lock_free_test boost::lockfree::queue is lockfree produced 4000000 objects. consumed 4000000 objects. real 0m1.745s user 0m6.886s sys 0m0.000s We can see that the lock free solution has better performance, about 50%. 2. then I test it in a PC server with centos 6.4 , and 8 core (CPU Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz ) boost version: 1.54 gcc version: 4.4.7 g++ version:4.4.7 The test result is that: time ./lock_test boost::lockfree::queue is not lockfree produced 4000000 objects. consumed 4000000 objects. real 0m3.900s user 0m2.593s sys 0m27.282s time ./lock_free_test boost::lockfree::queue is lockfree produced 4000000 objects. consumed 4000000 objects. real 0m5.470s user 0m43.105s sys 0m0.000s Non lock free solution is better than lock free solution. 3. I test it in a better PC server with centos 7.1 and 32 core CPU (Intel(R) Xeon(R) CPU E7-4820 v2 @ 2.00GHz) boost version: 1.53 gcc version: 4.8.3 g++ version: 4.8.3 time ./lock_test boost::lockfree::queue is not lockfree produced 4000000 objects. consumed 4000000 objects. real 0m3.023s user 0m1.929s sys 0m20.706s time ./lock_free_test boost::lockfree::queue is lockfree produced 4000000 objects. consumed 4000000 objects. real 0m9.804s user 1m14.900s sys 0m0.100s The lock free solution will be 3 times lower than the non-lock free solution! My question is that: 1. why lock free solution will get better performance in ubuntu but much slower in centos 6 and 7? Is it the issue of kernal or the gcc version or the boost version? The more cpu in the machine the worse performance for lock free solution? 2. In which case, we should use the boost lock free solution to get better performance? Best Regards! dennis

3 2

BOOST_PP_SEQ_ENUM troubles
by Cherotek Music 08 Jul '16

08 Jul '16

Hi, I'm trying to make a macro chain that expands something like this *A, B, C* into something like this *{"A", create<AFile>}, {"B", create<BFile>}, {"C", create<CFile>}* This is what I have come up with *#define FORMATS A, B, C // Add new formats here* *#define SEQ_FORMATS BOOST_PP_VARIADIC_TO_SEQ(FORMATS)* *#define ARG_PAIR(s, data, x) {#x, create<x##File>}* *#define SEQ_ARG_PAIRS BOOST_PP_SEQ_TRANSFORM(ARG_PAIR, ~, SEQ_FORMATS)* *#define ARG_PAIRS BOOST_PP_SEQ_ENUM(SEQ_ARG_PAIRS)* The SEQ_ARG_PAIRS macro does expand into *({"A", create<AFile>}) ({"B", create<BFile>}) ({"C", create<CFile>})* but ARG_PAIRS fails with the following error: test.cpp:20:1: error: macro "BOOST_PP_SEQ_SIZE_0" passed 2 arguments, but takes just 1 ARG_PAIRS ^ BOOST_PP_SEQ_ENUM_0 ({"B", create<BFile>}) ({"C", create<CFile>}) ({"A", create<AFile>}) ({"B", create<BFile>}) ({"C", create<CFile>}) Any ideas? thanks a lot

3 7

boost::any with const value types
by Robert Dailey 07 Jul '16

07 Jul '16

I'm finding that if I store a `char*` versus `char const*` in a boost::any object, that this impacts the behavior of boost::any_cast. I do not find this documented anywhere. For example, if I store a const qualified character pointer in a boost::any object, then I do `boost::any_cast<char*>(......)`, it will throw. Changing the type to `char const*` fixes it. Is this by design? I find this makes things more difficult to deal with since I don't always know if the type I'm getting is const or not. Also my implementation does not change depending on constness.

4 3

State of context and coroutine
by Michael Steinberg 06 Jul '16

06 Jul '16

Hello, I find myself working on a project which makes use of boost::context functionality which got moved to the detail namespace somewhen before booost 1.61 . Now this project is mimicing something along the lines of boost::coroutine on top of context. I could try to adapt to the new intended usage of context or change the setup to use coroutine. Hence my question is whether the public coroutine interface, specifically the asymmetric parts, is stable yet? Im seeing 1's and 2's there side by side, so I could imagine there's still deciding on a good interface going on. Kind Regards, Michael

4 12

Re: [Boost-users] Acquiring and rebuilding C++ libraries on Windows
by LeMay.Steve 06 Jul '16

06 Jul '16

Probably a great topic for CPPCON. Sent from my iPad From: Ernest Zaslavsky Sent: 7/5/16, 8:44 PM To: , Boost Subject: Re: [Boost-users] Acquiring and rebuilding C++ libraries on Windows Hi, And what happened to the native NuGet packages idea? It is quite convenient way to get, use and update third parties. From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric Mittelette Sent: Wednesday, July 06, 2016 2:49 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] Acquiring and rebuilding C++ libraries on Windows Hello I’m Program Manager at Microsoft, working on VC++ Libraries team (VC runtime, STL…) We are working on the spec of a tool to acquire 3rd party libraries on Windows. We are targeting mainly OSS libraries, our tool will help dev to rebuild locally from the source code on Windows. Today we have a proto, based on a port tree approach. (having a repo with the build script and the associated patch file) I wanted to have a discussion with the Boost community about this project, and how dev could acquire Boost this way. Feel free to contact me to initiate this discussion, we’ll be happy to share our idea and prototype with you and collect feedback and suggestions. Best, Eric Mittelette Senior Program Manager – Visual C++ (VCLib) Microsoft Corp. CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited.

1 0

filesystem path{}.string() interface brittle when developing cross platform
by Werner Erasmus 05 Jul '16

05 Jul '16

Firstly, I would like to than the author/s of filesystem for their great work and their time. I've recently written some code on Linux where I had to adapt a filesystem::path object to string. I noticed that the return value was of type [const std::string&], and used the same return value in my getter that exposed the underlying string. Moving over to windows, I had strange crashes (undefined behaviour) as result of the type under windows being converted to [std::string]. The reason for the "undefined behaviour" took me a while to figure out. While understanding why the author returned by value (Windows API underlying type not a std::string...), I think that for a specific type, the contract concerning return value "semantics" should no be broken. There is a significant difference between returning by const reference as opposed to returning by value. If the contract cannot be held, the decision should be made to (in the interest of consistency/clarity) to return the same type for all OS's/platforms if the code is to be considered platform independent. This might mean to compromise by returning by value, or to, in the case of Windows (where the underlying string has a different type), cache the string, or at the very least document a *BOLD* note that caution must be taken. I can comprehend that if conversion is required, return by value is the only option. I expect type consistency per type, as this to me is part of the contract of a function. I don't consider this a bug, but would appreciate some response. Kind Regards

3 2

[coroutine2] - exceptions from constructor fail
by Tamas.Ruszkai＠leica-geosystems.com 01 Jul '16

01 Jul '16

2 1