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

[BGL] Correct idiom for working with vertices.
by Matthew Markland 04 Nov '15

04 Nov '15

All: I'm building a graph on which I will be running betweenness centrality. This graph consists of a number of edges represented as pairs. For example 1 20 15 10 would represent an edge from 1<->20 and one from 15<->10. These are bidirectional. My initial code created a property_map for the centrality results and then walked through that map using num_vertices(g) as the limit for the for-loop. What I've realized now, though, is that when BGL generates the values for num_vertices (and the iterators for vertices also), it "fills in" the gaps. So, in the graph above there would be 20 vertices that would be interated through even though most of those have no relation to edges in the graph. So, I'm wondering what the usual idiom is in this situation. Should I instead iterator over edges and pull information from the source and target vertices of the edges? Thanks in advance for the information! Matt ---- Matthew Markland mwmarkland(a)outlook.com

2 1

Re: [Boost-users] Crashing Issue
by swati upadhyaya 04 Nov '15

04 Nov '15

hi I am using like this where RunningThreads_ is vector containing boost thread object pointer(handler).I am using interrupt() for the interruption of thread interruption_point() catching that interruption then joining.everytime its crashing in join() for me but for others who have the same configuration its working fine all of us has windos 8. For me also it was working last week but this week the same piece of code is crashing. :( RunningThreads_[i].handle->interrupt(); RunningThreads_[i].handle->join(); delete RunningThreads_[i].handle; On Thu, Feb 5, 2015 at 9:31 AM, swati upadhyaya <swatiupadhyaya(a)gmail.com> wrote: > RunningThreads_[i].handle->interrupt(); > LOG4CPLUS_INFO(root, "Thread Interrupted for " << > RunningThreads_[i].app_name << " successful"); > RunningThreads_[i].handle->join(); > LOG4CPLUS_INFO(root, "Waiting for thread to exit " << > RunningThreads_[i].app_name << " successful"); > delete RunningThreads_[i].handle; > LOG4CPLUS_INFO(root, "Thread handle for " << > RunningThreads_[i].app_name << " successfully deleted"); > //RunningThreads_.erase(i); > > On Wed, Feb 4, 2015 at 12:10 AM, Vicente J. Botet Escriba < > vicente.botet(a)wanadoo.fr> wrote: > >> Le 03/02/15 09:10, swati upadhyaya a écrit : >> >> In my code join() timed_joined() is crashing, I am using these API >> after interrupt(),Same piece of code is working for others but in my system >> its crashing, >> Is there some dependency problem I am using >> Boost version: 1.55.0 >> OS: Windows 8 >> IDE: Visual Studio 2010 >> >> Hi, >> >> it could help if you post the example and the backtrace. >> >> Which version/OS/compiler use others for which this works? >> >> Vicente >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users >> > >

3 2

[boost-test] print list of names of failing tests on failure
by Steve Lorimer 03 Nov '15

03 Nov '15

I don't believe there is currently a way to print only the list of tests which failed. --report_level=short only prints the numbers of passed and failing tests --report_level=detailed prints a very verbose list of all tests Is there a middle ground which will give me the names of tests which have failed, but not those which have passed? Something along the lines of: Test module "Master Test Suite" has failed with: 1 test case out of 9 failed 1 test case out of 9 aborted 1 assertion out of 30 failed Test case "foo_test" was aborted with: 1 assertion out of 1 failed TIA Steve

1 0

[boost::asio] [stream::ssl] stackful coroutine yield from SSL handshake in servername callback
by SamJam Liddicott 03 Nov '15

03 Nov '15

I'm testing a spoofing MITM SSL proxy based on boost::asio and boost::asio::stream::ssl, using boost 1.55 I register the tlsext_servername_callback, so that I can observe the called name during SSL handshake with the client. In the callback, I have the information needed to either get/create an appropriate SSL_CTX with certificates to use with the client, or start an SSL handshake with the server, to obtain the server certificate for re-signing and then put that back into the SSL_CTX to be passed to the client, before returning the tlsext_servername callback. It is clear that I must block the tlsext_servername callback from returning until I have the new SSL_CTX ready, which could take some time if I need to wait on a handshake with the real server. I can block return by performing a blocking handshake with the server, but then I consume one of the io_service threads merely blocking, and I don't want to waste them like that. I can successfully run it all as a new thread using blocking IO, in this form: ssl_connect(...) { boost::thread([...]() ({ sni_callback = [...](std::string server_name) { server.handshake(...); SSL_set_SSL_CTX(client.native_handle(), server.ctx)); }; client_socket.handshake(...); handler(); // really done by io_service.post }).detach(); } But I want to use stackful coroutines in the belief that thay are less costly and that I will be able to have more connections in progress (though I may have to link with BoringSSL). Using a coroutine spawn, I can convert the handshake with the server, like this: ssl_connect(...) { boost::asio::spawn(my_strand, [...](boost::asio::yield_context yield) { sni_callback = [...](std::string server_name) { server.async_handshake(..., yield[ec]); // <---- works nicely SSL_set_SSL_CTX(client.native_handle(), server.ctx)); }; client_socket.handshake(...); handler(); // really done by io_service.post }); } but the handshake with the client must remain blocking, otherwise, with: client_socket.async_handshake(..., yield[ec]); I get segfaults in the coroutine with unhelpful stack traces, mentioning only some SSL cleanup functions. However if the client connection hangs, then the client handshake can still hang and block a worker thread. My guess is that if the handshake with the client is not blocking, the SNI callback does not occur on the coroutine, and so I cannot properly block the return and possibly the use of yield in the SNI callback is invalid. If there is a solution that doesn't involve patching either libssl or stream::ssl, it will involve some asio_invoke_handler hooks. However, for that to work, the coroutine would have to be activated, but not to complete the async_handshake call. Instead it would be activated to handle the handshake read completion, leading to the parsing, SNI callback & return, further handshake write, and yield back to the io_service. I don't know if the coroutine/strand implementation can even do that -- be activated for work and not for return. So my first question is: is it likely possible to make coroutine do this? Looking in boost source detail/io.hpp for case engine::want_input_and_retry I notice: next_layer_.async_read_some( boost::asio::buffer(core_.input_buffer_), BOOST_ASIO_MOVE_CAST(io_op)(*this)); which seems to make no attempt to use asio_hanlder_invoke to allow it to be hooked, so that might need fixing. What sort of asio_handler_invoke hook would cause the handler to be invoked on the coroutine? Could strand.dispatch() do it? If it would, I'm not sure how to write such a hook either to work with argument dependent lookup, or to invoke in the coroutine. Otherwise I may as well stick to starting a scope-limited thread, and using blocking handshake operations. But I like to know the limits... Samjam

1 0

boost::math::cyl_bessel_j_zero: few NaN
by campagne 02 Nov '15

02 Nov '15

double order = (double)lcur + 0.5; unsigned int n_zeros; vector<double> zeros; boost::math::cyl_bessel_j_zero(order,1,n_zeros, back_inserter(zeros)); I'am running Boost 1.59 on Mac OS X Maverick for lcur = 0, I expect zeros filed with Pi, 2 Pi, 3Pi.... but the first two zeros I get NaN I get also other nan as for the 2nd zeros for lcur=1 Have you experienced such problem or I have a memory leak somewhere ? Thanks JE

2 1

Confused about the Boost.Build documentation
by Oodini 01 Nov '15

01 Nov '15

Hello, I wanted to read the doc of Boost.Build, but I find two documentations : 1. One from the link I can find on this page : http://www.boost.org/doc/ (at the booton, or at the bottom right corner, in th menu) 2. One I found throught from Google : http://www.boost.org/doc/libs/1_59_0/doc/html/bbv2.html I am not able to find it by navigating on the Boost site. Which page is the godd one ? Thanks.

2 4

[asio] Using io_service::poll() without pthread locking and unlocking
by ☂Josh Chia (谢任中) 31 Oct '15

31 Oct '15

I'm using boost::asio to do some TCP socket communication from a single-threaded program. The program performs asynchronous reads and writes and keeps calling io_service::poll() from a busy loop. I noticed from callgrind profiling that a significant portion of time is spent on pthread locking and unlocking from io_service::poll(). If I can get rid of the lock operations, the performance will improve significantly. Is there a way to get io_service to not use locks other than hacking the source code? It's a single-threaded application so the locking is unnecessary. The main reason I'm using asio is for the abstraction that allows me to write clean, simple, code, and hope I don't have to give up performance for simplicity. Josh

2 2

[icl] 'map::_add' ignores default-constructed value
by Filip Konvička 29 Oct '15

29 Oct '15

Hi, First of all thanks very much for the ICL! I'm using a boost::icl::interval_map with my own value type (struct V) and I have a custom value combining logic by passing boost::icl::inplace_et to the map and defining my own "operator&=" that provides the logic implementation. Now what happens is that my map ignores "m += make_pair(..., V())" because the default-constructed value is considered neutral due to: boost/icl/interval_base_map.hpp: ... interval_base_map<...>::_add(const segment_type& addend) { typedef typename on_absorbtion<type,Combiner, absorbs_identities<type>::value>::type on_absorbtion_; ... const codomain_type& co_val = addend.second; if(on_absorbtion_::is_absorbable(co_val)) return this->_map.end(); This 'if' returns without actually modifying the map. Is there some public API that I can use to tell my map that it should not consider any value 'absorbable'? And is it a good idea to change this? Thank you, Filip

1 0

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

29 Oct '15

Sorry this is a re-post because my email client had formatting enabled. 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

2 1

[Boost.Proto] implementing function call operators in expression trees
by Brook Milligan 29 Oct '15

29 Oct '15

I am trying to implement function call operators with Boost.Proto but cannot seem to figure out either how to set the expression trees up or how to evaluate them properly. The code below is simplified from the “checked calculator” example in the Proto documentation to focus on implementing a single identity function resulting from the Proto expression ‘identity(_1)’. The program prints the following function( terminal(9identity_) , terminal(0) ) result=0 [ expect 3 ] so I think the expression tree is correct. (I am, however, uncertain why the placeholder is reported as ‘terminal(0)’.) When the expression tree is evaluated with IdentityGrammar transform, the result is 0 not 3 as I would have expected if the placeholder value was used. The Proto documentation seems very thorough (at least after study), but is thin on the use of functions like this and is not helping me figure out the solution. I welcome any help that will point out the flaw(s) in this code for either setting up the expression tree or getting it evaluated correctly by calling the identity function with the correct argument. Thanks for your help. Cheers, Brook #include <boost/proto/proto.hpp> #include <boost/mpl/int.hpp> #include <boost/fusion/container/vector.hpp> #include <boost/fusion/container/generation/make_vector.hpp> namespace mpl = boost::mpl; namespace proto = boost::proto; namespace fusion = boost::fusion; template<typename I> struct placeholder : I {}; struct identity : proto::callable { typedef int result_type; int operator()(int a) const { return a; } }; struct identity_ {}; struct IdentityGrammar : proto::or_< proto::when< proto::terminal<placeholder<proto::_>> , proto::functional::at(proto::_state, proto::_value) > , proto::when<proto::terminal<identity_>, proto::_void> , proto::when< proto::function<IdentityGrammar, proto::terminal<proto::_>> , proto::and_< IdentityGrammar(proto::_child1) , identity(proto::_value(proto::_child1)) > > > {}; template<typename Expr> struct identity_expr; struct identity_domain : proto::domain<proto::pod_generator<identity_expr>, IdentityGrammar> {}; template<typename Expr> struct identity_expr { BOOST_PROTO_EXTENDS(Expr, identity_expr<Expr>, identity_domain) }; identity_expr<proto::terminal<identity_>::type> const identity = {{}}; identity_expr<proto::terminal<placeholder<mpl::int_<0> > >::type> _1; int main() { auto expr = identity(_1); proto::display_expr(expr); int result = IdentityGrammar()(expr,fusion::make_vector(3)); std::cout << "result=" << result << " [ expect 3 ]" << std::endl; return 0; }

1 0

Program Options: Omit positional arguments from help
by Florian Lindner 28 Oct '15

28 Oct '15

Hello, I have this piece of code: void getOptions(int argc, char *argv[]) { namespace po = boost::program_options; po::options_description desc("Artificial testing tool."); desc.add_options() ("help", "produce help") ("participant", po::value<std::string>(), "Participant Name"); po::positional_options_description pd; pd.add("participant", 1); po::variables_map vm; //po::store(po::parse_command_line(argc, argv, desc), vm); po::store(po::command_line_parser(argc, argv).options(desc).positional(pd).run(), vm); po::notify(vm); if (vm.count("help")) { std::cout << desc << std::endl; return; } } First question: Is the usage of po::store correct that way? I've found it somehwere on the internet but the documentation mentions no alternative parser call when using positional arguments. Main question: When using help it still displays --participant, albeit it's only a placeholder for the positional argument. Is there a way to hide a options or what is the correct way? Thanks, Florian

1 0

Missing something about Boost.Graph
by Dominique Devienne 28 Oct '15

28 Oct '15

We have a graph of relational tables, with the foreign keys being the edges of the graph. We're using boost::topological_sort() to sort the graph, and have struggled in the past with Boost.Graph. Recently we had cycles appearing in our graph, so I'm revisiting this code, and I think I must be missing something fundamental about Boost.Graph, because I get what I consider incoherent results. Here are the relevant code snippets. typedef std::pair<std::size_t, std::size_t> IndexPair; std::vector<IndexPair> edges; // fill edges with pairs of integers, in range [0, 111] (at the moment) using namespace boost; typedef property<vertex_color_t, default_color_type> GraphProperty; typedef adjacency_list<vecS, vecS, directedS, GraphProperty> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; Graph G(edges.begin(), edges.end(), edges.size()); size_t max_vrtx_index = 0; for (const auto& e : boost::make_iterator_range(boost::edges(G))) { size_t s = boost::source(e, G); size_t t = boost::target(e, G); max_vrtx_index = std::max(max_vrtx_index, s); max_vrtx_index = std::max(max_vrtx_index, t); } const auto G_vrtx_count = num_vertices(G); const auto G_edge_count = num_edges(G); if (G_vrtx_count != (max_vrtx_index + 1)) { std::cout << "Graph has " << G_vrtx_count << " vertices " "and " << G_edge_count << " edges, yet in reality " "our edges refer to at most " << max_vrtx_index << " vertices!" << std::endl; } This outputs: Graph has 1137 vertices and 1137 edges, yet in reality our edges refer to at most 111 vertices! How can num_vertices() and num_edges() return the same number? Why isn't num_vertices() returning 112 as I'd expect? I'm using 1.58. Thanks, --DD

2 2

[DLL] unclear how to specify calling convention for dll::import
by Konstantin Ivlev 27 Oct '15

27 Oct '15

Hello, I've just started using Boost.DLL in order to simplify loading of various WinApi functions exclusive to specific Windows versions, however, I've faced the issue (or may be it's just misunderstanding from my side). it's pretty well-known there are multiple calling conventions around - cdecl, stdcall, fastcall, etc. most of WinApi functions are in stdcall calling convention, while default one for MSVC 2015 is cdecl (unless compiler options are changed). I've read documentation on http://apolukhin.github.io/Boost.DLL/, as well as I've scanned source code a bit, but didn't find any avidence on how to specify calling convention of function I am importing. example from tutorial9 works just fine, as it uses timeGetTime function which has no arguments. however, if I modify example (see my code below copy-pasted from tutorial9) to import function with at least one argument or more (e.g. GetStdHandle) I receive the following debugger error: Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention. this indicates that Boost.DLL incorrectly interpreted stdcall function as cdeacl function that caused stack corruption. I've googled a bit about calling convention and boost, and found the following two definitions: #define BOOST_BIND_ENABLE_STDCALL #define BOOST_MEM_FN_ENABLE_STDCALL unfortunately adding them has no effect. if I add explicit __stdcall into the function typedef, then program no longer compiles #include <boost/dll/import.hpp> // for import #include <iostream> #include <windows.h> namespace dll = boost::dll; int main() { typedef HANDLE(GetStdHandle_fn)(DWORD nStdHandle); // function signature boost::function<GetStdHandle_fn> plugin = dll::import<GetStdHandle_fn>( // we import using C name, not alias! Using `import<>` "Kernel32.dll", // Windows dll "GetStdHandle" // function name ); std::cout << "timeGetTime() returned " << plugin(STD_OUTPUT_HANDLE) << std::endl; return 0; }

1 0

[signals2] connected signal not being called
by Glenn Ramsey 27 Oct '15

27 Oct '15

Hi, In a program I have a function connected to to a signal that is being called periodically. At a certain point the function inexplicably stops being called. Other functions that are connected to the same signal and same group are still being called at this time. As far as I am aware disconnect() has not been called and connection.connected() returns true and connection.blocked() returns false for this function. This seems very strange to me and I'm wondering if there is something that I have overlooked. It's not the sort of thing that could be reproduced with a simple example. What would be a good way to debug this? Glenn

2 2

Interest in a Boost.Chrono/Date library
by Vicente J. Botet Escriba 26 Oct '15

26 Oct '15

Hi, maybe some of you have already see the Howard Hinnant presentation at CppCOn2015 [1] about his new data-v2 library [2]. My prototype of Boost.Chrono/Date library ([3] ] was based on the Howard original library, but when we want to reach the maximum of performances we need to use a specific date class for each usage. This is what Howard explains in his marvelous presentation ans his tiny date library My post here wants to know if there is interest in a library providing what H.H. date library provides in Boost. Note that his data-v2 library yet doesn't provides as much as Boost.Date provides but IMHO it is much elegant and efficient. If there is enough interest, I will request you to do a first review of the H.H. Date-V2 library. Then once we have a consensus I will make my POC Chrono/Date library ready for review. H.H. Date-V2 is under MIT license, which IIRC is compatible with the Boost license. I don't know yet if would need to add this license, as my POC [3] is already a good starting point, nevertheless, I would like to know if there could be any issues about having the source under both licenses. Best, Vicente [1] https://www.youtube.com/watch?v=tzyGjOm8AKo [2] https://github.com/HowardHinnant/date [3] https://github.com/viboes/chrono_date/commits/master First commit Nov/2011 Last-Mars2014

2 2

[Log] linker errors after update from 1.57 to 1.59
by Glenn Ramsey 25 Oct '15

25 Oct '15

Hi, After updating a project to use Boost 1.59 from 1.57 I am getting link errors like this: Undefined symbols for architecture i386: "boost::log::v2_mt_posix::basic_formatter<char> boost::log::v2_mt_posix::parse_formatter<char>(char const*, char const*)", referenced from: boost::log::v2_mt_posix::basic_formatter<char> boost::log::v2_mt_posix::parse_formatter<char>(char const*) BOOST_LOG_DYN_LINK has been defined and the build works with 1.57. This is on OSX 10.10.5 with Xcode 6.4 and with command line builds using clang (Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)). Boost was built using this command line: ./b2 --prefix=$HOME/rp/boost-1_59_0 cxxflags="-stdlib=libc++ -arch i386 -mmacosx-version-min=10.7" linkflags="-stdlib=libc++ -arch i386 -mmacosx-version-min=10.7" --with-python --with-signals --with-thread --with-date_time --with-filesystem --with-regex --with-chrono --with-log link=shared architecture=x86 install What do I need to do fix this? Glenn

1 0

[BGL] adding an edge without modifying a graph?!
by Ireneusz Szcześniak 24 Oct '15

24 Oct '15

Hi, The subject sounds crazy, I know. But I need to add reverse edges so I can run a max-flow algorithm on my graph, and I would not like to modify the input graph. I can make a copy of the graph, modify it all right, run a max-flow algorithm, and discard the modified graph, but that would be inefficient. So I wonder whether someone could share some trick on how to do that, if this is possible. I was hoping to use boost::subgraph: create a root graph, create its subgraph, and then add reverse edges only to the root graph. Unfortunately, these edges also popped up in the subgraph. Thanks & best, Irek

2 3

[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