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

[context] Compiling error with context and bind
by José 09 Sep '14

09 Sep '14

2 1

[msm] extending msm::back::state_machine
by Manuel Schiller 09 Sep '14

09 Sep '14

Hi, I tried to enhance the backend of boost::msm by inheriting from boost::msm::back::state_machine. When doing so, I cannot access members of my subclass in the states. When compiling the attached example, I get this error message: *error: ‘class boost::msm::back::state_machine<fsm_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’ has no member named ‘test’* How can I "inject" extended_back_machine as the type being passed as "FSM" to the state? Bye Manuel #################################### template<typename FrontMachine> struct extended_back_machine : public boost::msm::back::state_machine<FrontMachine> { void test() { std::cout << "test" << std::endl; } }; struct fsm_ : public boost::msm::front::state_machine_def<fsm_> { struct State : public boost::msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&, FSM& fsm) { fsm.test(); } }; typedef State initial_state; }; int main() { typedef extended_back_machine<fsm_> fsm; fsm m; m.start(); return 0; } ####################################

3 3

[boost][container][static_vector] Stack or heap?
by Aaron Levy 08 Sep '14

08 Sep '14

Does the boost::container::static_vector allocate its memory on the stack or heap. From what I could make of the code, it seems to allocate on the stack. What happens if the requested size exceeds the stack size limits? Aaron

2 1

[boost][assign][bimap] Assign support for bimap
by Aaron Levy 08 Sep '14

08 Sep '14

Are there any Boost.Assign overloads available for Boost.Bimap? Aaron

2 2

linking with Intel compiler to Boost libs compiled with Visual Studio
by Damien 05 Sep '14

05 Sep '14

Hi, I'm trying to link to Boost 1.56 libs that I built with VS2013. We compile with both Intel and VS. We build Boost with layout=tagged (e.g. boost_serialization-mt-gd.lib), and these link fine with VS2013. When linking with Intel 2015 the linker complains about a missing library, looking for the layout=versioned lib name (e.g. libboost_serialization-iw-mt-gd-1_56.lib). Even if you specify the library name directly on the link line, it still complains. I'm sure this is just an include or #define issue but I don't know where to look. If anyone can point me in the right direction I'd be grateful. Cheers, Damien

2 2

Testers required
by Antony Polukhin 05 Sep '14

05 Sep '14

Hi, There is a big need in testers that have access to exotic platforms(zArch, MIPS) and compilers (Cray, IBM xlc ...). Could you please run `b2` in `boost/libs/type_index/test` and report results. This will help to test Boost.TypeIndex library and other libraries that depend on `demangle.hpp` I'll appreciate any help. Thanks in advance! -- Best regards, Antony Polukhin

1 0

[graph] Vertex order and VertexList type changes boykov_kolmogorov_max_flow result
by Michael J Iatauro 04 Sep '14

04 Sep '14

In the code below, using listS to store vertices results in vertex instantiation order changing the amount of flow computed by boykov_kolmogorov_max_flow. As given, it computes a flow of 0. If I move the instantiation of "T-" to be before "t-" or switch the VertexList parameter of adjacency_list to vecS, it computes the correct flow of 1000. Stepping through the code, it looks like when the max_flow function iterates over vertices that are targets of out-edges from the source, the call to get(m_in_active_list_map, v) at boykov_kolmogorov_max_flow.hpp:528 returns true for the second vertex, preventing it from getting added to m_active_nodes. I tested this using g++ 4.4.7 and with Boost 1.55 and 1.56. Has anybody else seen anything like this? Code follows: #include <boost/graph/adjacency_list.hpp> #include <boost/graph/boykov_kolmogorov_max_flow.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/graph_traits.hpp> #include <iostream> #include <limits> using namespace boost; typedef adjacency_list_traits<vecS, listS, directedS> Traits; typedef Traits::vertex_descriptor Vertex; typedef Traits::edge_descriptor Edge; typedef adjacency_list<vecS, listS, directedS, property<vertex_name_t, std::string, property<vertex_index_t, long, property<vertex_color_t, default_color_type, property<vertex_distance_t, long, property<vertex_predecessor_t, Edge > > > > >, property<edge_flow_t, double, property<edge_capacity_t, double, property<edge_residual_capacity_t, double, property<edge_reverse_t, Edge > > > > > Graph; void addEdge(Graph& g, const Vertex& source, const Vertex& target, const double capacity, const double reverseCapacity) { property_map<Graph, edge_reverse_t>::type rev = get(edge_reverse, g); Edge e1 = add_edge(source, target, g).first; Edge e2 = add_edge(target, source, g).first; put(edge_capacity, g, e1, capacity); put(edge_capacity, g, e2, reverseCapacity); rev[e1] = e2; rev[e2] = e1; } int main(void) { Graph g; property_map<Graph, vertex_name_t>::type nameMap = get(vertex_name, g); Vertex source = add_vertex(g); nameMap[source] = "source"; Vertex sink = add_vertex(g); nameMap[sink] = "sink"; Vertex tminus = add_vertex(g); nameMap[tminus] = "t-"; addEdge(g, source, tminus, 1, 0); Vertex Tminus = add_vertex(g); nameMap[Tminus] = "T-"; addEdge(g, source, Tminus, 1000, 0); Vertex Tplus = add_vertex(g); nameMap[Tplus] = "T+"; addEdge(g, Tplus, sink, 1000, 0); addEdge(g, Tplus, Tminus, 0, std::numeric_limits<int>::max()); double flow = boykov_kolmogorov_max_flow(g, source, sink); std::cout << flow << std::endl; return 0; } -- ------------------ Michael J. Iatauro Software Engineer QTS, Inc. NASA Ames Research Center Office: 650-604-0662 Mail stop: 269-2 P.O. Box 1 Moffett Field, CA 94035-0001

1 0

Batch job processing with Boost Spirit parser
by Michael Levine 04 Sep '14

04 Sep '14

I have been using Boost Sprit as a parser for a project that I have been working on lately. At this point, I have been trying to expand the software and, in doing so, have had the nagging feeling that there is something wrong with my overall design. In the best case, I am not making the best use of my tools, and in the worst case, I am concerned that the design/code is becoming overly brittle. As an aside, I don’t have a huge amount of programming experience with this type of application. A word of background / context : Essentially, the program performs batch ‘jobs’ which are specified in a text file (not dissimilar in that sense from a scheduler like Condor). Spirit parses these ‘Job Description’ files into ‘specification objects’ (my vocabulary) that are used with a builder pattern and factories to create the appropriate objects. I have some concerns about this which I will describe later. The job description (henceforth: JD) file should have 3 parts: 1. Data 2. Tools 3. Operations The Data section is just a list of data that is to be operated on. At this stage, this is just a vector of std::pair<std::string, std::string> containing an identifier and the path of the file. The ‘Tools’ and ‘Operations’ sections are likely composed of nested specifications (the resulting objects use either a decorator pattern or composite pattern – depending on the type of tool) – which was the main reason that I started using Spirit altogether. My question is really a request for some guidance – to better utilize the tools available: I have just received the requirement for section #3 (Operations), to be included in the JD file (previously it was assumed that this would be provided in a different manner). So – at this time, I have a working parser for the Data and Tools portions. I have concerns with the ‘Tools’ portion that I would like to correct and not duplicate in the ‘Operations’ section that I am to be working on next. At present, I am parsing the JD file mostly into strings, and vectors of boost::variant<int,double> -- the latter being a list of parameters in a completely arbitrarily imposed order. As I’ve previously mentioned, I have a few problems with this approach. - The parameters are required to be input in an arbitrary order. - Different ‘Tool’s and ‘Operation’s have different parameters that are required and/or optional. For the past weeks (I only work on this project on a very part-time basis), I have been going in circles trying to figure out a better way to do this. I have a strong suspicion that Fusion can be used for this. I am also concerned about over-complicating the design, but am weary of leaving the design too simplistic. I.e., I know that I can treat the parameters as a std::pair<std::string, boost::variant<int, double>> and then parse key-value pairs with a given delimiter. I am just not convinced that this is the best way to do this. I am able to use any Boost Library, and have no restrictions about compilers (I’m using a recent version of Clang, primarily, right now). The following is a selection of the data structures and Spirit grammar that I am using here: struct Tool_Spec; typedef std::vector<boost::variant<int, double> > Tool_Options_t; typedef std::vector<Tool_Spec > Children_Tool_t; typedef std::pair<std::string, std::string> Data_Spec; struct Job_Request { Data_Spec data_spec; Tool_Spec model_spec; Operation_Spec operation_spec; boost::optional<std::string> description; }; struct Tool_Spec{ std::string type; std::string data_designation; Tool_Options_t; options; Children_Tool_t children; boost::optional<std::string> designation; }; struct Operation_Spec{ /* Unknown at this time. Need help */ }; Datafile %= lit("@START") >> *Data_Description >> Tool_Description >> Operation_Description >> lit("@END") ; Data_Description %= lit('%') >> Datasource >> lit(';') ; Datasource = Designator >> lit(':') >> Designator ; Designator %= +(char_("0-9a-zA-Z/._") | char_('-') ); Comment_Designator %= +(char_("0-9a-zA-Z/._, ()") | char_('-')); Tool_Description %= Designator >> ':' >> ('@' >> Designator) >> '[' >> +Options >> ']' >> -('{' >> *Child_Tool >> '}') >> -qi::lexeme[Comment_Designator] >> ';' ; Child_Tool %= Designator >> ':' >> ('@' >> Designator) >> '[' >> +Options >> ']' >> -('{' >> *Child_Tool >> '}') >> -qi::lexeme[Comment_Designator] >> ';' ; Options %= (int_ | double_ ) % '|';

1 0

[graph] filtered graph and num_vertices
by Miklós Tóth 03 Sep '14

03 Sep '14

Hi All, I have a graph, and I use a filter like this. struct FilteredGraph : public boost::filtered_graph<SomeGraph, SomeFilter > { FilteredGraph(SomeGraph g) : boost::filtered_graph<SomeGraph, SomeFilter>(g, SomeFilter(g)) {} }; I want to use in this function. template <class Graph>void some_graph_function(const Graph& g) { const size_t vertex_num = boost::num_vertices(g); //... } Like this: FilteredGraph fg(g) some_graph_function(fg); And I get: > error: no matching function for call to 'num_vertices(const FilteredGraph&)' > const size_t vertex_num = boost::num_vertices(g); > ^ >From the boost 1.55 documentation: > The num_vertices <http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/filtered_graph.html#num…> and num_edges <http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/filtered_graph.html#num…> functions do not filter > before returning results, so they return the number of vertices or > edges in the underlying graph, unfiltered [2] <http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/filtered_graph.html#2>. So it should work. What am I missing? Regards, Miklós

1 0

Re: [Boost-users] [graph] Unique vertices using setS
by Nicholas Dahm 03 Sep '14

03 Sep '14

> On Tue, Sep 2, 2014 11:29 AM MDT Jeremiah Willcock wrote: > >> >> >>On Sun, Aug 31, 2014 10:53 PM MDT Nicholas Dahm wrote: >> >>>On Wed, Aug 27, 2014 7:24 PM EDT Nicholas Dahm wrote: >>> >>>Is there any place where I could enforce unique properties? (i.e. not add a new vertex if it's properties are the same as an existing vertex) >>> >>>Not that I know of. >>> >>>My graph is actually an implicit search tree for an A* search so there's lots of nodes which will be revisited via different paths. My current thought is to create the new vertex (which is a search tree state), then simply iterate through all existing vertices to see if any are identical in properties. However if the vertices were sorted by their properties in a set (i.e. weakly ordered), this would be much faster. >>> >>>Do you need to store the explored part of the search tree explicitly? You could instead use a custom graph type with your choice of vertex descriptor, then use associative_property_map to check for multiple visits to the same state. >>> >>>No need to store the explored part. I have exactly zero clue on how to create a custom graph type with a special vertex descriptor. At current I've gotten around it by having a "set" of vertex descriptors which use a custom "less" function which actually checks the vertex bundled properties instead of the descriptor. It's not the perfect solution but it wasn't very ugly either so it'll do. If you have a link to info on how to create custom graph types with special vertex descriptors please do let me know >> >>Please look at https://github.com/wpm/Boost-Implicit-Graph-Example for a simple example. You only need to do the incident edge iterator and property parts from that example, and can skip the other iterator types. There is also an A*-specific example at https://github.com/wpm/Astar-Maze-Solver, but it stores more of the data explicitly and uses existing BGL graph types. >> >>-- Jeremiah Willcock >> > >There is also http://www.boost.org/doc/libs/1_56_0/libs/graph/example/knights-tour.cpp as an example, but you'll probably need the BGL book for its documentation. > >-- Jeremiah Willcock Ok I'm getting the hang of it now. Thanks for all your help Jeremiah :)

1 0