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

[1.60] Beta date?
by Joaquin M López Muñoz 26 Nov '15

26 Nov '15

Hi, Is there a planned date for Boost 1.60 beta (we have beta RC3 so far) or do we intend to jump directly to 1.60 RC? I'm asking because I've got a couple of fairly minimal commits that run succesfully in develop and I'd like to merge to release before it's too late: https://github.com/boostorg/multi_index/commit/ 1f4d33012bb0537d6bd5667aed8a02d29eb1ed26 https://github.com/boostorg/flyweight/commit/ adda32bfa9af8a4427affc41c64b792660ffffae Thank you, Joaquín M López Muñoz Telefónica

4 3

[Statechart] question about event processing rules in orthogonal states.
by Ernesto Rodriguez Reina 25 Nov '15

25 Nov '15

Hi everyone, The event processing order of a normal (non-orthogonal) state is first the innermost and if not handled (or forwarded) then it parent, and that behaviour is repeated upward until the event is discarded (or deferred). But when we are in the presence of orthogonal states, then the behaviour I am getting is a bit different, for example given the following statechart: <code> struct EvTest : sc::event< EvTest > {}; struct Test; struct Inner1; struct Inner2; struct Machine : sc::state_machine< Machine, Test > {}; struct Test : sc::simple_state<Test, Machine, mpl::list<Inner1, Inner2> >{ typedef sc::custom_reaction< EvTest > reactions; sc::result react( const EvTest){ std::cout << "Test" << std::endl; // return discard_event(); return forward_event(); } }; struct Inner1 : sc::simple_state<Inner1, Test::orthogonal< 0 > >{}; struct Inner2 : sc::simple_state<Inner2, Test::orthogonal< 1 > >{ typedef sc::custom_reaction< EvTest > reactions; sc::result react( const EvTest){ std::cout << "Inner2" << std::endl; return forward_event(); } }; </code> When received the event "EvTest" the output I am getting is: <output> Test Inner2 Test </output> That means that the handler in the state "Test" is called twice. If in the handler at test we discard instead of forwarding then we get that only the handler of "Test" is called. I thought that without taking into account if the children are orthogonal or not, the event will be processed first by the children (all of them in the case of orthogonal state until one discard or defer the event), and event is not discarded (or deferred) then the parent process the event. It is that OK? If so why I am getting that weird behaviour in my example? Any thoughts and comments are more than welcome. Best, Ernesto Rodriguez Reina

1 0

boostboost::filesystem::detail::copy_file undefined when using c++14
by ken 25 Nov '15

25 Nov '15

Hello I am building an application that uses boost libraries that I also complied. This is on a mac os x 10.9 system using gnu gcc 5.2 installed with mac ports. I built the boost 1.59.0 libraries as instructed and built the application without any problems (after a few tries). Then I changed the c++ language standard for the build of the application to -std=gnu++14 (the default is gnu++11). However, I now get the following error during the linking phase: g++ -std=gnu++14 -U_WIN32 -Dunix -DNDEBUG -O3 -DTIXML_USE_STL -DBOOST_FILESYSTEM_VERSION=3 -fmessage-length=0 -I[...] -lboost_date_time-mt -lboost_filesystem-mt -lboost_regex-mt -lboost_system-mt -lboost_locale-mt -lboost_thread-mt -lboost_chrono-mt [...] Undefined symbols for architecture x86_64: "boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)", referenced from: [...] ... ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status [...] I rebuilt the boost libraries with the -std=gnu++14 option and verified that they are using the same std library, but I still got the same error when linking those libraries to my application. I removed the c++14 option from the application build and the error went away. So next I took a look at the functions in libboost_filesystem-mt.a and for lib/libboost_filesystem-mt.a(operations.o) I found this function: 0000000000007720 T __ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_NS1_11copy_optionEPNS_6system10error_codeE or boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::detail::copy_option, boost::system::error_code*) I see that this differs from what the linker is looking for in that copy_option (third parameter) is in the detail name space. Any ideas on where to go from here? Thanks

1 0

Iterating "root" vertices with boost::graph
by Isaac Lascasas 25 Nov '15

25 Nov '15

Hello I want to enumerate all vertices with zero input edge count in a graph, I am using DFS right now: struct vertex_visitor : public boost::default_dfs_visitor { std::vector<vertex_t> Output; void discover_vertex(vertex_t v, graph_t const& g) { graph_t::in_edge_iterator edgeIt, edgeEnd; tie(edgeIt, edgeEnd) = boost::in_edges(v, g); if (edgeIt==edgeEnd) Output.push_back(v); } }; vertex_visitor vis; boost::depth_first_search(g, boost::visitor(v)); However I don't know how to cleanly stop execution after depth 0 inside my visitor and I can't figure out a better way to archieve this. Since I am fairly new to boost graph I supose that I'm missing something. Thanks.

2 1

Extend boost binary serialization with varints encoding
by Ernest Zaslavsky 24 Nov '15

24 Nov '15

Is it feasible to provide boost binary serialization with varint encoding capabilities? How does one achieve that? Can one just create template overload of "save" and "load" for unsigned integrals? anything else should be changed? [Read More]<http://feeds.feedburner.com/~r/sizmek-blog/~6/1> [http://www.sizmek.com/Sizmek.png]<http://www.sizmek.com/>

3 8

[type_erasure] BOOST_TYPE_ERASURE_MEMBER within namespace?
by Nat Goodspeed 23 Nov '15

23 Nov '15

I find that using BOOST_TYPE_ERASURE_MEMBER within my own namespace fails with compilation errors: myprog.cpp:23:1: error: no template named 'concept_interface'; did you mean '::boost::type_erasure::concept_interface'? This is with Boost 1.57, compiled with Apple clang from Xcode 7.1.1. Moving BOOST_TYPE_ERASURE_MEMBER to the global namespace allows successful compilation. I would rather avoid putting my has_member names into the global namespace. How to achieve that?

2 1

Consistency when removing items from boost multi-index using an inner iterator
by Hovnatan Karapetyan 23 Nov '15

23 Nov '15

Hi, I already posted this same question on StackOverflow, since I have not gotten an answer yet reposting it here too. Suppose I am iterating over a boost::multi_index using one of the two indices. Then if I start iterating using the other index and erasing an element according some criteria, does that invalidate the upper iterator? E.g., struct person { string name; string last_name; string age;} typedef multi_index< person, index_by< ordered_non_unique<person, string, &person::name>, ordered_non_unique<person, string, &person::age> >> PersonCollection; PersonCollection pc; //insert some elements into pc auto index0 = pc.get<0>();auto range0 = index0.equal_range("John");while (range0.first != range0.second) { auto index1 = pc.get<1>(); auto range1 = index1.equal_range(34); while (range1.first != range1.second) { if (range1.first->last_name == "Smith") range1.first = index1.erase(range1.first); else ++range1.first; } ++range0.first;} So in this case, is the range0 iterator always valid? Thanks! Hovnatan

2 2

[BGL]Using a function for weightmap to dijkstra_shortest_path
by Amit Prakash Ambasta 23 Nov '15

23 Nov '15

Hi, I am trying to write use BGL.dijkstra to calculate a shortest path in a time dependent network where edge.cost C(u, v) is a function of distance(a)edge.source and a variable wait time dependent on Edge.departure i.e. Cost(Edge(u,v), D(u)) = Wait(Edge(u, v).departure, D(u)) + Edge(u, v).delay The cost function ( and edge property is defined as): struct Eonnection { Eonnection(const Vertex source, const Vertex destination, const double departure, const double duration, const double cost) { this->source = source; this->destination = destination; this->departure = departure; this->duration = duration; this->cost = cost; }; Vertex source; Vertex destination; double departure; // Time of departure double duration; // Duration of traversing edge double cost; // Actual cost of traversing Edge std::pair<double, double> dyn_cost(std::vector<std::pair<double, double> > distances, double t_max) { std::pair<double, double> d_parent = distances[this->source]; double t_parent = d_parent.first; double c_parent = d_parent.second; double t_time_of_day = fmod(t_parent, 24 * 3600); double t_delay = t_time_of_day <= this->departure ? this->departure - t_time_of_day: this->departure + (24 * 3600 - t_time_of_day); double t_total = t_parent + t_delay + this->duration; if(t_total < t_max) { std::cout << "Edge usable with cost " << c_parent + this->cost << ", " << t_total << std::endl; return std::pair<double, double>(c_parent + this->cost, t_total); } else { std::cout << "Edge unusable" << std::endl; return std::pair<double, double>(std::numeric_limits<double>::infinity(), std::numeric_limits<double>::infinity()); } }; }; I'm trying to call dijkstra as dijkstra_shortest_paths_no_color_map( g, source, boost::make_iterator_property_map(pred.begin(), get(boost::vertex_index, g)), boost::make_iterator_property_map(distances.begin(), get(boost::vertex_index, g)), boost::make_transform_value_property_map( boost::bind<std::pair<double, double> >(&Eonnection::dyn_cost, _1, _2, distances, 24 * 3600 * 3), get(boost::edge_bundle, g) ), get(vertex_index, g), smaller, combiner, std::pair<double, double>(std::numeric_limits<double>::infinity(), std::numeric_limits<double>::infinity()), std::pair<double, double>(0, 0), vis ); However, this does not seem to work. How can I pass the weights as a dynamic function to dijkstra_shortest_paths?

1 0

Levelization of DAG in Boost graph -- trying again
by bhattach 20 Nov '15

20 Nov '15

Not sure why my previous attempt to post a new topic didn't succeed -- page kept showing a note that the post was not accepted by the mailing list. Trying one more time. ------------------------ Although I've been using graphs for 30+ years, I'm new to Boost Graph Library. I'd like to do "classical levelization" of a DAG -- as is commonly used in applications like digital logic simulation, etc -- whereby level(v) = max_level(set of predecessors of v) + 1 I used record_distances() with breadth_first_search() and suitably defined property map, but I suspect that's returning level(v) = min_level(set of predecessors of v) + 1 Is there a simple way to use breadth_first_search() to get the level numbers I want, or do I need to write my own levelization routine? Thanks in advance for comments/suggestions/pointers. Debashis Bhattacharya -- View this message in context: http://boost.2283326.n4.nabble.com/Levelization-of-DAG-in-Boost-graph-tryin… Sent from the Boost - Users mailing list archive at Nabble.com.

2 4

Asymmetry between function_input_iterator and function_output_iterator
by Daniel Hofmann 20 Nov '15

20 Nov '15

I experienced some issues and asymmetric behavior in the function input and output iterator interfaces [1] [2]. See the following small self-contained example: const auto two = make_function_input_iterator([]{ return 2; }, infinite{}); copy_n(two, 3, ostream_iterator<int>(cout, "\n")); This does not compile --- but it should, in my opinion. The problem is that make_function_input_iterator has two overloads, one that takes a Function& and one that takes a Function*. Shouldn't this rather take a Function by-values as the stdlib does, and let the user pass a std::ref if needs be? Then we could also pass lambdas, making this a viable feature in C++11 and later. Without being able to pass lambdas, I see almost no value in the input iterator. On a related note, the documentation does not say that the make_function_iterator always needs an Input state. In addition, the link to the function input iterator PDF on the overview page [3] 404s. Now to the function output iterator: const auto dummy_out = make_function_output_iterator([](int) {}); copy_n(nums, 3, dummy_out); Surprisingly this compiles since make_function_output_iterator takes its functor by const-ref (with a defaulted functor argument, which does not really make sense in my opinion, since the reason for the make_* function is type inference through the passed parameter). Note, though, how the function output iterator lives in the same iterators namespace as the functio input iterator, but is not inside the iterator directory. The respective headers are located at: boost/function_output_iterator.hpp boost/iterator/function_input_iterator.hpp I would love to understand the design decisions behind these, and if it would be possible to "modernize" them without breaking much of the interfaces. Cheers, Daniel J H [1] http://www.boost.org/doc/libs/1_59_0/libs/iterator/doc/function_input_itera… [2] http://www.boost.org/doc/libs/1_59_0/libs/iterator/doc/function_output_iter… [3] http://www.boost.org/doc/libs/1_59_0/libs/iterator/doc/index.html

1 0