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

[BGL] augmenting for a max-flow algorithm
by Ireneusz Szcześniak 24 Oct '15

24 Oct '15

Hi, I would appreciate it if someone could define the term "augmenting" used in the documentation of the max-flow algorithms: "First, the directed graph G=(V,E) that represents the network must be augmented to include the reverse edge for every edge in E." Does it simply mean that I need to add to the graph a reverse edge? In the documentation of the boykov_kolmogorov_max_flow algorithm it's stated point-blank: "The directed graph G=(V,E) that represents the network must include a reverse edge for every edge in E". Cool, so I know that I need to add the edge with the add_edge function. To use a max-flow algorithm I need to modify my input graph. So I guess "augmenting" means just "including/adding", right? Thanks & best, Irek

1 0

BGL, swapping two graphs can invalidate vertex descriptors?
by Paolo Bolzoni 24 Oct '15

24 Oct '15

Dear list, I had to fix a bug in a program of mine using the boost graph library. In the program I need to add and remove vertices quickly, so I used listS both for edges and vertices. Besides, I need to refer to vertices with special ids (that are integers), so I added to each vertex a integer and to the graph itself a map between the ids and the vertices. The interface ensures that when vertices are added and this data structures are updated properly. For reference I put the whole (minified) graph definition after the email. Now, I had a crash when using boost::out_edges in some part of the programs and not in others. After some debugging it really seems that it happens that the vertex descriptors, that are addresses to the vertices, change after a swap. Unfortunately I could not manage to make this behaviour in a small example so I am still unsure and I decided to ask here. It is possible that swapping two graphs (with listS as OutEdgeList and VertexList) invalidates the vertex descriptors? Yours faithfully, Paolo #include <boost/graph/adjacency_list.hpp> namespace graph_prop { struct vertex { int id{}; }; struct edge { int lenght{}; }; struct graph; } typedef boost::adjacency_list< boost::listS, boost::listS, boost::undirectedS, graph_prop::vertex, graph_prop::edge, graph_prop::graph > Graph; namespace graph_prop { struct graph { std::unordered_map<int, Graph::vertex_descriptor> ids{}; }; }

1 0

problems with linking...
by Witold E Wolski 24 Oct '15

24 Oct '15

In a project which vcproj files generated with cmake I am getting the following link error fatal error LNK1104: cannot open file 'libboost_date_time-vc120-mt-gd-1_59.lib' The generate link command (VS- project -> properties -> Linker -> command line) contains however: "C:\boost\boost_1_59_0\lib\boost_date_time-vc120-mt-gd-1_59.lib" both files are present in my boost binary build. Any idea why this mixup is taking place libboost_date_time vs. boost_date_time and how I can fix the problem? Best regards Witold -- Witold Eryk Wolski

2 2

[MSM] Solution for: fatal error C1202: recursive type or function dependency context too complex
by Mark Bartosik 21 Oct '15

21 Oct '15

I have had a major headache while using MSM eUML state transition tables, thankfully I've found a simple solution.First MSM and especially eUML are great, and that's why I persevered to find a solution. Here's the problem: Declaring a complex eUML state transition table may result in the compiler generating an error. BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((// row_1,// row_2,// ...// row_a,// row_b,// row_c,// // Eventually the Microsoft compiler VS2008,2010,2012,2015 will all explode with fatal C1202: recursive type or function dependency context too complex), transition_table ); I haven't tried with gcc. The solution is to break the state table in two smaller parts rather than one big table: BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((// row_1,// row_2,// ...), transition_table_part_1 ); BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((// row_a,// row_b,// row_c ), transition_table_part_2 ); typedef boost::mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table; // No error, even though it contains just as many rows [Waffle warning] I think that what's happening is that once the compiler has fully described the transition_table_part1 it unwinds what it is doing, it is able to unwind and 'bank' transition_table_part1 as just being a type in it's memory, and when it comes to generate transition_table via boost::mpl::join_view it just constructing the resulting type list from two sets of previously 'banked' types. This is I think why I can still nest a sub-state machine which is on the limit of the complexity of state transition table it can contain; even though nesting state machines recursively references state transition tables. Things that did not work: [ more waffle ] There are some other solutions that I tried before I had the Eureka moment. One was to try to hide a sub-state machine within a concrete class but that didn't work because the outer fsm needs to see the inner stt. Another way was to implement a sub-state machine as a concrete state (not fsm), and then add a process_event method on the class which delegated to a member fsm which was hidden from the outer fsm, I got this to work, but it did not solve the problem, and I had to abandon use of exit_pt_, although it may have brought down compile times. Another helpful advantage of this solution is that the memory required by the compiler is significantly reduced. Christophe:Would you consider adding the example above to the MSM documentation, I would suggest under: Chapter 4, Compilers / Performance, Compilers Corner Also under: Chapter 5, Questions Answers and Tips: Question: Why do I get "fatal C1202: recursive type or function dependency context too complex" Answer: Likely because a state transition table has become two complex. Split the state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts. Question: Why does my compiler generate a fatal out of memory fatal error. Answer: Likely because a state transition table has become two complex. Try and split the most complex state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts. - Mark Bartosik

1 0

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