- Boost-users - lists.boost.org

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

04 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 04 Nov '15

04 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 03 Nov '15

03 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 02 Nov '15

02 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 30 Oct '15

30 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 29 Oct '15

29 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 29 Oct '15

29 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