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

[interprocess] Determine size of managed_shared_memory
by Kai Benndorf 12 Oct '19

12 Oct '19

Hi all, I want to create a managed_shared_memory in exactly the size I needed. Therefore I do something like this: size = sizeof( common_managed_shared_memory ); size += sizeof( MyClassInSharedMem ); managed_shared_memory segment(create_only, "name", size ); MyClassInSharedMem allocates itself some memory by segment->allocate(). I added this also to the size, but get a boost::interprocess::bad_alloc exception on allocating this additional memory. Are there some magic bytes I forgot to add? Many thanks in advance Kai

3 2

boost::filtered_graph filtering on vertex color... if I only had a colormap
by Brian Davis 19 Jul '19

19 Jul '19

Lets say I have a graph g (of type graph_t) and a color map (boy I wish I had a colormap): typedef boost::property_map<graph_t, boost::vertex_color_t>::type color_map_t; or is it? auto indexmap = boost::get(boost::vertex_index, g); auto colors = boost::make_vector_property_map<boost::default_color_type>(indexmap); or maybe? auto indexmap = boost::get(boost::vertex_index, g); auto colors = boost::make_vector_property_map<boost::vertex_color_t>(indexmap); or possibly some goop found on the internet? boost::make_iterator_property_map(color_map.begin(), boost::get(boost::vertex_index, data_->g), color_map[0]) or other internet goop? typedef boost::property_map<GraphType, boost::vertex_color_t>::type color_map_t; color_map_t colorMap; boost::color_map(colorMap)) or other internet goop?? std::vector<int> colorMap(num_vertices(g), boost::white_color); so confused... (certainly not surprised why bgl is not a part of stl) Can someone help explain the various types and ways of specifying colormaps and the logic for each way and means? and a function (if I could get that far without VS syntax highlighter going bonkers and gobs of compiler errors.. you know the type): make_pretty(g, colormap ) which colors the graph colormap and a filter struct for boost::filtered_graph<Graph, EdgePredicate, VertexPredicate> (where I wonder why if I only want to filter vertices I have to set boost::keep_all for EdgePredicate... sigh... I know the answer... and also know how long it found me to find/figure out boost::keep_all - and if you are looking for boost::keep_all and found it here... your welcome ;-) ) and modifying (probably incorrectly) boost::filtered_graph example to: template <typename ColorMap> struct vertex_color_filter_eq { vertex_color_filter_eq() { } vertex_color_filter_eq(ColorMap colormap/*, boost::default_color_type c*/) : m_colormap(colormap)/*, m_c(c)*/ { } template <typename Vertex> bool operator()(const Vertex& v) const { return 0 < get(m_colormap, v); //return c < get(m_colormap, v); } ColorMap m_colormap; //boost::default_color_type m_c; }; auto indexmap = boost::get(boost::vertex_index, g); auto colors = boost::make_vector_property_map<boost::default_color_type>(indexmap); // some where here I would call make_pretty(g, colors) typedef property_map<graph_t, boost::vertex_color_t>::type ColorMap_t; vertex_color_filter<ColorMap_t> filter(colors); // boost::filtered_graph<graph_t, boost::keep_all, VertexPredicate> boost::filtered_graph<graph_t, boost::keep_all, vertex_color_filter> fg(g, filter); // Later say if I could get it compile and better if it compiled and worked I could move on and auto color = boost::red_color; typedef property_map<graph_t, boost::vertex_color_t>::type ColorMap_t; vertex_color_filter<ColorMap_t> filter(colors, color); boost::filtered_graph<graph_t, boost::keep_all, vertex_color_filter> fg(g, filter); Maybe if I color them yellow, I can then reach the wizard pull back the curtain and ask how to create a color map... If I only had a color map.

4 6

mcgregor_common_subgraphs usage/complexity/performance/runtime
by Julian Wolf 01 Sep '18

01 Sep '18

Hello everyone, I'm new to Boost and today I tried to use the mcgregor_common_subgraphs functions but can't find an explanation why the function shows such bad performance when I use it. According to the documentation [1] the algorithm runs in O(V1 * V2) for the entire space with V being the number of vertices in the two graphs. So not great, but I'd expect that to run in reasonable time for graphs with less than 100 vertices. But in my case it doesn't, therefore any help appreciated whether I have some error or misconception on my side or whether this is expected performance. What I'm trying to achieve: I want to check whether two graphs have a common subgraph of size x. x depends on the size of smaller graph, I'm using a factor y for this with 0 < y < 1. With smaller values for x (e.g. x = 0.7 * V1) the example returns very fast, which makes sense since a smaller part of the search space needs to be explored. If I increase the factor to 0.8 * V1 or even run through the whole search space the program does not terminate within 10 minutes (where I canceled) I'll attach a working example as well as two graphs (44 and 46 vertices) showing the behaviour described. # gcc CommonSubgraph.cpp -o common_subgraph_example -lboost_graph -lstdc++ # time ./common_subgraph_example 0.7 graph1.dot graph2.dot Factor 0.7 Size: 30 real 0m0.043s # time ./common_subgraph_example 0.8 graph1.dot graph2.dot Factor 0.8 ^C real 10m39.741s My system runs openSUSE Tumbleweed with Boost 1.67 > rpm -q --whatprovides /usr/include/boost/graph/mcgregor_common_subgraphs.hpp libboost_headers1_67_0-devel-1.67.0-2.3.x86_64 Thank you! Julian [1] https://www.boost.org/doc/libs/1_68_0/libs/graph/doc/ mcgregor_common_subgraphs.html

2 2

Testing and faking ASIO I/O objects
by Cristian Morales Vega 31 Aug '18

31 Aug '18

How is people around here testing code which uses ASIO? I guess something like GIVEN("SOMETHING THAT STARTS BY DOING A NAME RESOLVER IS STARTED") fakeResolver.async_resolve("www.google.com", "80", HandlerCallingConnect); // This stores the completion handler (and an executor_work_guard) internally WHEN("THE RESOLVER RETURNS WITHOUT ERROR") fakeResolver.completeWithFakeResult("1.2.3.4", error_code()); // This post() the completion handler with the arguments you give it here io_context.poll(); THEN("A CONNECTION IS ATTEMPTED") EXPECT_CALL(fakeSocket, async_connect()); would be nice. But the "stores the completion handler" part doesn't look that simple. I have found some attempts online, but they seems to store the completion handlers into a vector of std::function and post them through std::bind, so possibly using the wrong executor, etc. There is any good set of ASIO I/O object fakes available?

2 2

linker errors with latest Visual Studio 15.8.2 update
by Damien 30 Aug '18

30 Aug '18

All, It looks like with 15.8.2 you might need to rebuild if you are linking to Boost compiled with earlier versions in the 15.6 or 15.7 series. Screens full of unresolved symbols..... Just a heads-up. Damien

1 0

[boost.test] parsing runtime arguments
by Olaf Peter 27 Aug '18

27 Aug '18

Hi, how get an 'user' API for the boost.test like this: testsuite_xyz -- --help or even testsuite_xyz -- --save-path=/foo to get the user aspects. I know I can get the args by int argc{ framework::master_test_suite().argc }; char** argv{ framework::master_test_suite().argv }; Further, at test/include/boost/test/utils/runtime/cla/parser.hpp are some utils used by boost.test self. Anyway, the problem rises to get the behaviour desribed above, simply using a global fixture with: fixture::fixture() { int argc{ utf::framework::master_test_suite().argc }; char** argv{ utf::framework::master_test_suite().argv }; for (int i = 0; i != argc; ++i) { std::cerr << "test_observer_fixture: " << argv[i] << "\n"; } } doesn't give the expected results - all the BOOST_AUTO_TEST_SUITE test cases are called even they depend on this arguments. Thanks, Olaf

2 3

Boost.Test BOOST_TEST/BOOST_REQUIRE_MESSAGE message arg problems
by Olaf Peter 27 Aug '18

27 Aug '18

Hello Boost Users, for my project I'm testing using BOOST_AUTO_TEST_SUITE and data driven test sets (BOOST_DATA_TEST_CASE). The goal is to check the proper working of a parser by checking success as such and compare the result with a "expected" data (string) vector. In case of parse error, I want to write the captured cout/cerr by boost.test into a file. In case of compare error the parsed result also shall be written to a file. The fragments show the concept/current state: namespace x3_test { // aka utils .... /* [Detect if boost test case failed]( * https://stackoverflow.com/questions/18466857/detect-if-boost-test-case-fail…) */ bool current_test_passing() { using namespace boost::unit_test; auto const id = framework::current_test_case().p_id; auto const test_results = results_collector.results(id); return test_results.passed(); } std::string report_diagnostic(fs::path const& test_case_name, std::string const& input, std::string const& result) { ... if(!x3_test::current_test_passing()) { // only write in case of failed test test_case_result_writer result_writer(test_case_name); result_writer.write(result); } return ss.str(); } } // x3_test ... BOOST_AUTO_TEST_SUITE(.... BOOST_DATA_TEST_CASE( declaration, dataset.input() ^ dataset.expect() ^ dataset.test_case_name(), code, expect_AST, test_case_name) { using attribute_type = ast::declaration; auto const parser = parser::declaration; x3_test::testing_parser<attribute_type> parse; auto [parse_ok, parsed_AST] = parse(code, parser); BOOST_TEST(parse_ok); BOOST_REQUIRE_MESSAGE(parse_ok, x3_test::report_diagnostic(test_case_name, code, parsed_AST) ); BOOST_TEST(parsed_AST == expect_AST, btt::per_element()); BOOST_REQUIRE_MESSAGE(x3_test::current_test_passing(), x3_test::report_diagnostic(test_case_name, code, parsed_AST) ); } BOOST_AUTO_TEST_SUITE_END() After some testing, the error count is twice the real (obviously here) but it's all above a work arround. It seems, that BOOST_REQUIRE_MESSAGE evaluates always the message predicate (shown by using --log_level=all) nevertheless the test case successed or failed. If failed it is streamed to the console. My first thoughs where that the message is called only in case of test failure which isn't true. The problem is now, that my report_diagnostic function write the test output (parsed_AST) to a special dir/file for later evaluating etc. The intuitive way would be: std::string report_diagnostic(fs::path const& test_case_name, std::string const& input, std::string const& result) { ... test_case_result_writer result_writer(test_case_name); result_writer.write(result); return ss.str(); } BOOST_REQUIRE_MESSAGE(parse_ok, // call diagnostic only in failure case and write then x3_test::report_diagnostic(test_case_name, code, parsed_AST) ); BOOST_REQUIRE_MESSAGE((parsed_AST == expect_AST, btt::per_element()), // call diagnostic only in failure case and write then x3_test::report_diagnostic(test_case_name, code, parsed_AST) ); Hence not depending on current_test_passing() any more. How to get this? Further, how can I get the captured std::cerr in case of '!parse_ok' inside report_diagnostic? Thanks, Olaf

2 10

[signals2] Warn unused result
by Deven 24 Aug '18

24 Aug '18

Hi, I am using boost::signals2 library for event callback mechanism. The event register callback function returns a boost::signals2::scope_connection object for optional disconnect by the function registering itself. I want to mandate using the returns result (scoped_connection) object by the user. So, I use the gcc attribute "__attribute__( ( warn_unused_result ) )" with the function. The problem is that the compiler does not warn for unused result. Any ideas, why would this happen? I am using Linux with g++ 4.8.4 and c++11 is enabled. Boost version: 1.67.0 I have attached a minimal working example. Thanks, -Deven

1 0

Setting cxxflags for intel compiler
by Michalke, Simon 23 Aug '18

23 Aug '18

Hi, in order to compile boost I need to tell the intel compiler which gcc version to use. I am trying to achive this with a user-config.jam using intel-linux : icpc : <cxxflags> -gcc-name=gcc-7 -gxx-name=g++-7 ; But none of the flags appear in the compile log. Which syntax am I supposed to use to get them working? Regards, Simon

3 2

[multi_index] Introducing C++17 terse key specification syntax
by Joaquin M López Muñoz 22 Aug '18

22 Aug '18

Following some ideas discussed about a year ago, I've added a new boost::multi_index::key construct allowing for a very terse specification of predefined key extractors in C++17 compliant environments. For instance, given struct phonebook_entry { std::string family_name; std::string given_name; std::string phone_number()const; }; int num_calls(const phonebook_entry&); a classical definition like typedef multi_index_container< phonebook_entry, indexed_by< ordered_unique< const_mem_fun<phonebook_entry,std::string,&phonebook_entry::phone_number> >, ordered_unique< global_fun<const phonebook_entry&,int,num_calls> >, ordered_non_unique< composite_key< phonebook_entry, member<phonebook_entry,std::string,&phonebook_entry::family_name>, member<phonebook_entry,std::string,&phonebook_entry::given_name> > > > > phonebook; can now be written as typedef multi_index_container< phonebook_entry, indexed_by< ordered_unique< key<&phonebook_entry::phone_number> >, ordered_unique< key<num_calls> >, ordered_non_unique< key<&phonebook_entry::family_name,&phonebook_entry::given_name> > > > phonebook; If you have a C++17 compiler, you can play with this new feature by simply copying https://github.com/boostorg/multi_index/blob/develop/include/boost/multi_in… into your local Boost installation. More info at https://www.boost.org/doc/libs/develop/libs/multi_index/doc/tutorial/key_ex… https://www.boost.org/doc/libs/develop/libs/multi_index/doc/reference/key_e… Comments and suggestions, specially before Boost 1.69 ships and this becomes more or less frozen, are most welcome. Best regards, Joaquín M López Muñoz

1 0