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

Can't build Boost::atomic
by Rui Pacheco 28 Dec '14

28 Dec '14

I've extracted a number of Boost's sub projects as source into my project using bcp. I've set CMake to find the Boost library under my project and not the one installed on my system:https://gist.github.com/ruipacheco/bae9f6694f5760da90b2 <https://gist.github.com/ruipacheco/bae9f6694f5760da90b2> I'm now trying to build my project but Boost::atomic fails while trying to find a file that indeed has not been extracted: https://gist.github.com/ruipacheco/954d0cf0dbb8ece7db75 <https://gist.github.com/ruipacheco/954d0cf0dbb8ece7db75> Is there a pre-processing step I missed with Boost when extracting the libraries? Why is it referencing a file that doesn't exist? -- Rui Pacheco

1 0

[boost-users][boost/numeric/ublas/matrix.hpp]: How to use SQL query to create boost matrix?
by It neophyte 28 Dec '14

28 Dec '14

Dear all I've read some matrix documentation (see below) and did not experience any difficulty in compiling codes: http://www.boost.org/doc/libs/1_42_0/libs/numeric/ublas/doc/matrix.htm However I am using SQL API to query data from c++, and wondering how I can build a boost price matrix. *Ps*: table contains 3 columns: name (*string* type), date (*datetime* type), price (*double* type) 1/While retrieving the query data, my screen output is as follows: aaaaa 2014-12-22 30.1 aaaaa 2014-12-21 27.7 bbbbb 2014-12-22 13.2 bbbbb 2014-12-21 10.3 ccccc 2014-12-22 80.4 ccccc 2014-12-21 79.9 2/My aim is to create a following price matrix (here 2 by 3) as: 30.1 13.2 80.4 27.7 10.3 79.9 Thanks in advance and Regards

1 0

[Test] Calling BOOST_MESSAGE too early results in malformed xml output from Boost.Test
by Martin Ba 26 Dec '14

26 Dec '14

Hi! First, I'm on 1.44 and won't get around to test it on a newer version any time soon, so I'll just throw it in anyway: I've hit the case that when the executable running boost.test is calling BOOST_MESSAGE from a BOOST_GLOBAL_FIXTURE, the message is generated *before* the unit test runner is full initialized (the message "Running ## test cases..." is displayed *after* the Message). When writing xml output, this means that the `<Message>`is generated before the `<TestLog>` root, resulting in malformed xml. I can fix this quite easily on my side, since I've [customized my logger anyway][1], I'll just have to make sure unit_test_log_formatter::log_start is always called first for the xml case, but it's still a buggy thing imho. cheers, Martin [1] : http://stackoverflow.com/questions/26505229/how-to-log-boost-test-output-to…

2 3

[Serialize] How to serialize a class with NO serializable data
by Merrill Cornish 25 Dec '14

25 Dec '14

I applied the PIMPL idiom to one of my larger classes, and it worked great. The visible class records the API with public functions and NO data member except the pointer to the implementation class. That pointer should not be serialized because it is created automatically when the visible class is instantiated. However, if I put NO serialization code in the visible class, the visible class won't (as I understand it) be instantiated when the archive is loaded. (I'm still far away from the point where I can try the archive load for myself.) Should I define the serialize<> function for the class, but with an empty body, since there are no data members to be saved?

2 1

Re: [Boost-users] [boost] [core] [addressof.hpp] [addressof_test2.cpp] ISO C++ says that these are ambiguous
by Sergey Sprogis 25 Dec '14

25 Dec '14

Peter Dimov wrote: > That's probably because of the __SUNPRO_CC workaround at addressof.hpp line 110: > #if (defined( __BORLANDC__ ) && BOOST_WORKAROUND( __BORLANDC__, > BOOST_TESTED_AT( 0x610 ) ) ) || defined( __SUNPRO_CC ) > return boost::detail::addressof_impl<T>::f( v, 0 ); > #else > return boost::detail::addressof_impl<T>::f( > boost::detail::addr_impl_ref<T>( v ), 0 ); > #endif .... Thanks Peter, Exactly, this is the reason for addressof_test2.cpp test's failure with Oracle Studio 12.4 compiler. The only issue here is that there is 5 months old opened bug with proposed fix to cure this: https://svn.boost.org/trac/boost/ticket/10311 I'd really appreciate it if someone will pay attention to this bug, and will insert proposed simple 1 line fix in trunk area. Thanks, Sergey

1 0

[TEST] Tests registered manually never exectued....
by Witold E Wolski 23 Dec '14

23 Dec '14

Im trying to manually register unit tests following the example at : http://www.boost.org/doc/libs/1_57_0/libs/test/doc/html/utf/user-guide/test… My registration code looks like follows: boost::unit_test::test_suite* init_unit_test_suite(int argc, char* argv[]) { boost::unit_test::test_suite* ts2 = BOOST_TEST_SUITE("test_suite2"); ts2->add(BOOST_TEST_CASE(&liveViewTest)); ts2->add(BOOST_TEST_CASE(&checkImageFormats)); ts2->add(BOOST_TEST_CASE(&testRethrowException)); boost::unit_test::framework::master_test_suite().add(ts2); return 0; } The init_unit_test_suite function is entered and returns but non of the added tests is ever exectued. regards -- Witold Eryk Wolski

2 1

[boost] [compute] Review period extended till December 30 + sum up
by Antony Polukhin 23 Dec '14

23 Dec '14

Hi, Review period of Compute library extended till December 30. Some notes and answers to them that were pointed out during review so far: * Some of the algorithms could be tuned for a specific hardware - Library author is working on a auto-tuning solution and improves existing algos * Why OpenCL C API used instead of C++ API? - C++ API had issues, C API allows a bit more control. No C++ API for OpenCL 2.0 * API is not N4105 compatible, library is not N*** compatible - This could be easily fixed by a library that will use Compute as a backend * Some of the algorithms return futures while other work with command queues - This is because of the OpenCL design + async chains/futures would be probably added later * Not all the types of the Khronos API are supported - A few types are not documented yet, there's a patch in the works which would allow the Khronos C++ types to be passed into Compute algorithms * A few type related errors could be detected at compile time - This will be fixed, more asserts would be added to runtime only checkable places. Report issues to the tracker https://github.com/kylelutz/compute/issues * On small data sets CPU algorithm would work faster than a GPGPU. How about implicitly dispatching algo on CPU in those cases? - The call on whether to execute the algorithm should be left up to the user. While library author agrees that this would be a useful feature, he just don't think Compute is the right place for that logic. * How about providing way to do chains of async operations - This is a big task that will be solved some day. * How about providing Boost.ASIO like error handling via throw and error_code - Implementing an approach like ASIO's wouldn't be that difficult. Thanks to all the reviewers for spending their time and providing useful comments so far! -- Best regards, Antony Polukhin

1 0

interprocess::rbtree_best_fit assertion failure with vector resize
by John Harris 22 Dec '14

22 Dec '14

I encountered this with 1.56 and 1.57 under heavy allocation load where I repeatedly resize an interprocess vector<unsigned char>. The only way I was able to get around it was to switch to the simple_seq_fit allocation algorithm. The assertion is assert(FALSE), and so I'm wondering if the algorithm doesn't handle all cases where there is a single-byte type for the vector. The stack below is from a core dump, and so the "Cannot access memory" errors are not necessarily indicative of bad pointers. #3 0x0000003dc2a2b820 in __assert_fail () from /lib64/libc.so.6 #4 0x00007f869a166793 in boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*>::copy_n_and_update (this=0x7f8698264b80) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/detail/advanced_insert_int.hpp:118 #5 0x00007f869a165fd6 in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert_expand_backwards<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > ( this=0x7f85adc00a40, new_start=0x7f85adc165a0 <error: Cannot access memory at address 0x7f85adc165a0>, new_capacity=199624, pos=0x7f85adc31974 <error: Cannot access memory at address 0x7f85adc31974>, n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2783 #6 0x00007f869a164c0b in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert_no_capacity<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > (this=0x7f85adc00a40, pos=..., n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2265 #7 0x00007f869a1639ec in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > (this=0x7f85adc00a40, pos=..., n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2328 #8 0x00007f869a16241a in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert_at_end<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > (this=0x7f85adc00a40, n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2365 #9 0x00007f869a1604e5 in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_resize<boost::container::value_init_t> (this=0x7f85adc00a40, new_size=178780, u=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2151 #10 0x00007f869a15de56 in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::resize (this=0x7f85adc00a40, new_size=178780) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:1213 #

1 0

[Random] normal distribution different behaviour 1.55 vs 1.57
by Thomas M 21 Dec '14

21 Dec '14

Hi, I have just switched an existent project from boost 1.55.0 to 1.57.0 and my test suites diagnosed a divergence in program (a simulation) results. I have tracked down the issue to different behaviour in the normal distribution random variates generator. Below is a simple program (run under VS 2012, Update 4) that outputs random variates for a uniform and a normal distribution; comparing the output between 1.55.0 and 1.57.0 it turns out that the first bunch of uniformly distributed variates is identical, and then all others variates (both bunches of normally distributed variates as well as the second bunch of uniformly distributed variates) diverge. Neither for 1.56.0 nor 1.57.0 does the change-log list an update to the random numbers library, so first I am puzzled why the libraries behave differently (though [Math] has undergone some changes -> propagation to [Random]?). Second, it is not clear to me why for the first bunch of uniformly distributed variates the results are identical, while for the second, after normally distributed variates were generated, the are not. It appears that the generation of normally distributed variates changes the whole state of the random numbers engine in a different manner [e.g multiple engine calls ??]. Any insight into what is going on here is much appreciated. And foremost: Is any of 1.55 or 1.57 bugged, that is one should be clearly preferred over the other? many thanks, Thomas #include <ostream> #include <iostream> #include <fstream> #include "boost/random.hpp" void test_rng() { typedef boost::mt19937 rnengine_t; typedef boost::uniform_01<double> uniform_distr_t; typedef boost::normal_distribution<double> normal_distr_t; typedef boost::variate_generator<rnengine_t &, uniform_distr_t> uniform_gen_t; typedef boost::variate_generator<rnengine_t &, normal_distr_t> normal_gen_t; uniform_distr_t uniformDistr; normal_distr_t normalDistr(0, 1); rnengine_t rnEngine; rnEngine.seed(100); uniform_gen_t uniformGen(rnEngine, uniformDistr); normal_gen_t normalGen(rnEngine, normalDistr); std::ofstream outFile("randomNumbers.txt"); outFile.precision(16); int n = 20; for (int outer = 0; outer < 2; ++outer) { for (int i = 0; i < n; ++i) outFile << "Uniform-distr variate #" << (n*outer) + i + 1 << ": " << uniformGen() << std::endl; for (int i = 0; i < n; ++i) outFile << "Normal-distr variate #" << (n*outer) + i + 1 << ": " << normalGen() << std::endl; } } int main() { test_rng(); return 0; }

5 8

Boost.container iterator_traits and flat_map
by gast128 21 Dec '14

21 Dec '14

Hello all, I have a problem here which boils down to the non-constness of iterator_traits for const_iterator of flat_map: void Foo() { typedef boost::container::flat_map<int, int> Int2IntFmap; Int2IntFmap::const_iterator it2; std::iterator_traits<Int2IntFmap::const_iterator>::value_type::first_type& r2 = it2->first; } 1>d:\develop\shared\main\test\testcommon\testgeneral\nctstgenhmhandlemap.cpp(59): error C2440: 'initializing' : cannot convert from 'const int' to 'int &' Anyone an idea or should I use decltype instead?

1 0