- Boost-users - lists.boost.org

Newbie
by Gagan Kumar 21 Oct '15

21 Oct '15

I am interested in Open Source and want to contribute in BOOST, can you guide me from where should I start.

2 1

what is the problem with my async_read_some function?
by 李楠 20 Oct '15

20 Oct '15

hi all! i have a problem with the async_read_some function. i code a client to connect a server, after login the server will send a lot of FAST(FIX Adapted for Streaming) Data constantly. i just use ip::tcp::socket.async_read_some function to read the data from server, but the interface of the server software sometime show that there are some data package wait for send(maybe my client not receive then immidiately).but, when i use a commercial client to connect and receive data from the server, there is no data package wait for send on the server. my code: BODY_LEN = 1024 * 1024 * 4//4M boost::array<char, BODY_LEN> body_; void client::login_handler(const boost::system::error_code& ec, std::size_t bytes_transferred) { if (ec) { error_.code = ec.value(); strncpy(error_.msg, ec.message().c_str(), ERROR_MSG_LEN - 1); error_.msg[ERROR_MSG_LEN - 1] = '/0'; glog.error("login_handler get an error: %s", error_.msg); return; } socket_.async_read_some(boost::asio::buffer(body_), boost::bind(&client::login_handler, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); static bool first = true; if (first) { heartbeat_inteval_ = 10; first = false; send_heartbeat(); } } there is a deadline_timer to send heartbeat to server every 10 seconds , user the same socket_ . i user asio handler tracking to debug, and found that sometimes between the async_read_some function call and their callback function call are more than 100ms, i don't kown why becasue the server send data always, and other commercial client is ok? @asio|1445319300.343750|25*26|socket@00840104.async_receive @asio|1445319300.343750|<25| @asio|1445319300.390625|>26|ec=system:0,bytes_transferred=24605 @asio|1445319300.390625|26*27|socket@00840104.async_receive @asio|1445319300.390625|<26| @asio|1445319300.578125|>27|ec=system:0,bytes_transferred=15805 @asio|1445319300.593750|27*28|socket@00840104.async_receive @asio|1445319300.593750|<27| @asio|1445319300.781250|>28|ec=system:0,bytes_transferred=3939 @asio|1445319300.781250|28*29|socket@00840104.async_receive @asio|1445319300.781250|<28| @asio|1445319300.781250|>29|ec=system:0,bytes_transferred=8858 @asio|1445319300.796875|29*30|socket@00840104.async_receive @asio|1445319300.796875|<29| @asio|1445319300.796875|>30|ec=system:0,bytes_transferred=23906 @asio|1445319300.796875|30*31|socket@00840104.async_receive @asio|1445319300.796875|<30| @asio|1445319300.796875|>31|ec=system:0,bytes_transferred=25124 @asio|1445319300.796875|31*32|socket@00840104.async_receive @asio|1445319300.796875|<31| @asio|1445319300.921875|>32|ec=system:0,bytes_transferred=18061 @asio|1445319300.937500|32*33|socket@00840104.async_receive @asio|1445319300.937500|<32| @asio|1445319301.125000|>33|ec=system:0,bytes_transferred=19960 @asio|1445319301.125000|33*34|socket@00840104.async_receive @asio|1445319301.140625|<33| @asio|1445319301.140625|>34|ec=system:0,bytes_transferred=11680 could someone give some suggest? thanks a lot!

2 1

Boost compilation error under OS X 10.8.5
by Sebastian Sulger 20 Oct '15

20 Oct '15

Dear Boost Users list, I have an issue trying to compile a project under Mac OS X 10.8.5 using Boost libraries, version 1.34.1. I am using Xcode 4.6.3 and accompanying Command Line Tools. This must be an OS X specific issue, since the project compiles under CentOS Linux. I am asking this on the list in hopes that someone has used Boost in OS X development and has maybe come across a similar issue. I attach an excerpt of the compiler messages below. I have tried googling for the error, but can't seem to find satisfying answers. Please let me know if you can think of something from the top of your head or, which is more likely, if you need more info (e.g., source code excerpts) to be able to help me. Thank you very much, Best, Sebastian ######## g++ -DPARC -DCPPPA_EXPORT= -fPIC -fno-common -D__STDC_LIMIT_MACROS -g -fno-inline -Wpointer-arith -Wwrite-strings -Wno-deprecated -Wreturn-type -W -I/usr/local/include -O2 -I../../src/include -I../../LexBase/src -I/include -I/usr/local/include/boost-1_34_1 -I/Users/sebastiansulger/projects/xle/dev/xfr/src/../../bgdb -Idb_client -I./ -I../include -Ifacts -Irules -Ichoices -Iterms -Imatches -Idriver -Iparser -Itriples -Iprolog -Idebug -Inew_parser -o terms/TermStorage.o -c terms/TermStorage.cpp In file included from terms/TermStorage.cpp:9: In file included from terms/TermStorage.h:28: In file included from ./Types.h:26: In file included from /usr/local/include/boost-1_34_1/boost/functional/hash.hpp:10: /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:487:20: error: call to 'hash_value' is ambiguous return hash_value(val); ^~~~~~~~~~ /usr/include/c++/4.2.1/ext/hashtable.h:595:16: note: in instantiation of member function 'boost::hash<long long>::operator()' requested here { return _M_hash(__key) % __n; } ^ /usr/include/c++/4.2.1/ext/hashtable.h:587:16: note: in instantiation of member function '__gnu_cxx::hashtable<std::pair<const long long, unsigned int>, long long, boost::hash<long long>, std::_Select1st<std::pair<const long long, unsigned int> >, std::equal_to<long long>, std::allocator<unsigned int> >::_M_bkt_num_key' requested here { return _M_bkt_num_key(__key, _M_buckets.size()); } ^ /usr/include/c++/4.2.1/ext/hashtable.h:522:18: note: in instantiation of member function '__gnu_cxx::hashtable<std::pair<const long long, unsigned int>, long long, boost::hash<long long>, std::_Select1st<std::pair<const long long, unsigned int> >, std::equal_to<long long>, std::allocator<unsigned int> >::_M_bkt_num_key' requested here size_type __n = _M_bkt_num_key(__key); ^ /usr/include/c++/4.2.1/ext/hash_map:219:22: note: in instantiation of member function '__gnu_cxx::hashtable<std::pair<const long long, unsigned int>, long long, boost::hash<long long>, std::_Select1st<std::pair<const long long, unsigned int> >, std::equal_to<long long>, std::allocator<unsigned int> >::find' requested here { return _M_ht.find(__key); } ^ terms/TermStorage.h:97:46: note: in instantiation of member function '__gnu_cxx::hash_map<long long, unsigned int, boost::hash<long long>, std::equal_to<long long>, std::allocator<unsigned int> >::find' requested here TsHashMapIter iter = mParent->mHashMap.find(t); ^ terms/TermStorage.cpp:85:47: note: in instantiation of member function 'powerset::xfr::TermHashStorage<long long>::hashInsert' requested here uint32_t index = (uint32_t) mIntTermStorage.hashInsert(intVal); ^ /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:105:24: note: candidate function inline std::size_t hash_value(int v) ^ /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:110:24: note: candidate function inline std::size_t hash_value(unsigned int v) ^ /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:115:24: note: candidate function inline std::size_t hash_value(long v) ^ /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:120:24: note: candidate function inline std::size_t hash_value(unsigned long v) ^ /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:229:24: note: candidate function inline std::size_t hash_value(float v) ^ /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:234:24: note: candidate function inline std::size_t hash_value(double v) ^ /usr/local/include/boost-1_34_1/boost/functional/hash/hash.hpp:239:24: note: candidate function inline std::size_t hash_value(long double v) ^ 1 error generated. make[1]: *** [terms/TermStorage.o] Error 1 make: *** [build] Error 2 Sebastian-Sulgers-MacBook-Pro:dev sebastiansulger$ -- Sebastian Sulger FB Sprachwissenschaft Universität Konstanz http://ling.uni-konstanz.de/pages/home/sulger

1 0

[BGL] Assertion failed / memory leak in r_c_shortest_paths.hpp
by Alberto Santini 20 Oct '15

20 Oct '15

In the following 2-years old thread, a memory leak was experienced when using r_c_shortest_paths of the boost graph library. Jeremiah Willcock added a bunch of assertions to the code, to help identify the problem. https://groups.google.com/forum/#!topic/boost-list/W1muJiw85pA I think I now have a reproducible version of this, which I believe might be a bug. I would like some input before opening a bug report. Here is the gist: https://gist.github.com/alberto-santini/32c19530dcefb784d0f2 It contains: 1) graph.txt which contains a dump of the graph that exposes the problem 2) boost_bug.cpp which is the code used to build the graph from file and do the labelling 3) terminal_output.txt which contains the command used to compile and what happens when running the code It has been tested on Mac OS X 10.11 with GCC 5.2 and Boost 1.58. The programme doesn't necessary trigger the assertion at each run. There are runs in which it completes successfully, runs in which it segfaults without triggering any assertion and times in which it's aborted by the failed assertion. The failed assertion is: Assertion failed: (p_cur_label->b_is_valid), function r_c_shortest_paths_dispatch, file /usr/local/include/boost/graph/r_c_shortest_paths.hpp, line 472. I would like to know if you experience the same behaviour and can confirm (or at least make an educated guess) wether or not this is a bug in r_c_shortest_paths.hpp. Thanks, AS

1 1

Re: [Boost-users] [interprocess] Interprocess mutex not working / throwing exception when trying to write lock
by nav999 19 Oct '15

19 Oct '15

Dear Admin, It's ok if this does not reach the mailing list. I'm putting it up here as the answer, so that anyone browsing this Nabble forum will find it. The answer is here: http://stackoverflow.com/questions/33197889/boost-interprocess-mutex-crashe… -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[intrusive] accessing the hook type?
by Oliver Kowalke 18 Oct '15

18 Oct '15

I'd like to determine the hook type of an intrusive container (intrusive::list): template< typename List > void do_link( List & lst) { static_assert(std::is_same< typename List::???, my_hook_type >::value); lst.push_back( * this); }

2 2

boost spirit qi/karma char parsing/generating
by Ernest Zaslavsky 18 Oct '15

18 Oct '15

The question why does it treated as string character when my intention is to work with 8bit integral type? int8_t/uint8_t does not help either on most platforms it is just a define for signed/unsigned char. So, the broader question, how do you work with “byte” type when it is always treated as character? And the main question how do I force qi/karma to treat “char” as a number? P.S. cast to short is an obvious solution but it is not elegant [Read More]<http://feeds.feedburner.com/~r/sizmek-blog/~6/1> [http://www.sizmek.com/Sizmek.png]<http://www.sizmek.com/>

1 0

Boost.Python extension
by Jeff Archer 16 Oct '15

16 Oct '15

I am trying to use Boost.python to create a python extension. I have created the hello_ext example but find that I cannot import it. I am always getting the error "ImportError: No module named 'hello_ext'". Boost 1.59.0 Python 3.5 Visual Studio 2015

2 1

Re: [Boost-users] [interprocess] Interprocess mutex not working / throwing exception when trying to write lock
by Malko 16 Oct '15

16 Oct '15

Copying over here my initial reply: Hi, 1. Your lockWithWriteLock and lockWithReadLock create a lock, which locks on construction and unlocks on destruction, hence when the function returns no lock is held on the mutex. 2. The fact that you put a scope here makes me think that your intention is for the lock to be unlocked at the end of this scope (which it won't, as it is unlocked way before, as per #1). { std::cout<<"Program 1: Before first locking -------------------------- 1 v\n"; temp.sharedMutex->lockWithWriteLock(); const unsigned int SLEEP_TIME_IN_SECOND = 60; std::cout<<"Program 1: sleep for "<< SLEEP_TIME_IN_SECOND << "\n"; sleep(SLEEP_TIME_IN_SECOND); std::cout<<"Program 1: Finished sleeping\n"; } In this case though, you would perform the wait in bold while still holding the lock, and hence preventing the 2nd program from locking it. Once out of the scope you destroy the object right away. NOTE: both the issue in #1 and #2 lead to your first program possibly deleting the mutex before the 2nd program is done with it. Which leads to the issue you are experiencing. 3. If you need to have the 1st program wait for the 2nd program to be done, then do not use sleeps, use a condition_variable. -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… Sent from the Boost - Users mailing list archive at Nabble.com.

1 1

[Thread] Problems compiling an example from the docs
by Malko 16 Oct '15

16 Oct '15

Hi, I am trying to compile the following example: http://www.boost.org/doc/libs/1_59_0/doc/html/thread/synchronization.html#t… #include <boost/thread.hpp> #include <boost/thread/future.hpp> int parallel_sum(int* data, int size) { int sum = 0; if ( size < 1000 ) for ( int i = 0; i < size; ++i ) sum += data[i]; else { boost::future<int> handle = boost::async(parallel_sum, data+size/2, size-size/2); sum += parallel_sum(data, size/2); sum += handle.get(); } return sum; } int main() { int data[] = {1,2,3,4,5,6,7,8,9,10}; int a(parallel_sum, data, 10); return 0; } It does not compile because future is not a type in boost and async has the wrong signature. The future error goes away by defining BOOST_THREAD_PROVIDES_FUTURE, but I can not find this mentioned anywhere in the docs, I found out only looking on stack overflow. The async signature seems to require a function of arity 0. This is clang 3.4 output using Boost.1.59 and C++03: XXX/src/futtest.cpp:12:33: error: no matching function for call to 'async' boost::future<int> handle = boost::async(parallel_sum, data+size/2, size-size/2); ^~~~~~~~~~~~ /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/thread/future.hpp:3545:3: note: candidate function template not viable: requires 2 arguments, but 3 were provided async(launch policy, R(*f)()) { ^ /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/thread/future.hpp:3609:3: note: candidate function template not viable: requires 2 arguments, but 3 were provided async(launch policy, BOOST_THREAD_FWD_REF(F) f) { ^ /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/thread/future.hpp:3961:3: note: candidate function template not viable: requires single argument 'f', but 3 arguments were provided async(R(*f)()) { ^ /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/thread/future.hpp:3978:3: note: candidate function template not viable: requires single argument 'f', but 3 arguments were provided async(BOOST_THREAD_FWD_REF(F) f) { ^ XXX/src/futtest.cpp:22:7: error: excess elements in scalar initializer Is there more macro to be used to enable this to compile? Thanks P.S. It would be nice to have all the info about macro configuration for future (and async, if it has any) in the docs. -- View this message in context: http://boost.2283326.n4.nabble.com/Thread-Problems-compiling-an-example-fro… Sent from the Boost - Users mailing list archive at Nabble.com.

2 3