- Boost-users - lists.boost.org

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

problem with asio signal_set and consecutive signals
by Lutz Schneider 02 Sep '14

02 Sep '14

Hi, I have a program and would like to stop it by sending SIGINT for writing some data to a file instead of exiting immediately. However, if the user of the program sends SIGINT again then the program should quit immediately and forget about writing data to a file. For portability reason I would like to use boost::asio for this purpose. My initial (simplified) approach (see below) did not work. Is this not possible or am I missing something? handler seems to be called only once (printing out the message) and the program always stops when the loop has reached the max iteration number. void handler( const boost::system::error_code& error, int signal_number) { if (!error) { static bool first = true; if(first){ std::cout << " A signal(SIGINT) occurred." << std::endl; // do something like writing data to a file first = false; }else{ std::cout << " A signal(SIGINT) occurred, exiting...." << std::endl; exit(0); } } } int main(){ // Construct a signal set registered for process termination. boost::asio::io_service io; boost::asio::signal_set signals(io, SIGINT); // Start an asynchronous wait for one of the signals to occur. signals.async_wait(handler); io.run(); size_t i; for(i=0;i<std::numeric_limits<size_t>::max();++i){ // time stepping loop, do some computations } std::cout << i << std::endl; return 0; } Cheers, LS

2 3

Re: [Boost-users] [graph] Unique vertices using setS
by Jeremiah Willcock 02 Sep '14

02 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

1 0

Re: [Boost-users] [graph] Unique vertices using setS
by Jeremiah Willcock 02 Sep '14

02 Sep '14

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

1 0

Very interesting problem with TCP sockets
by Igor Mironchik 02 Sep '14

02 Sep '14

Hi guys, I was trying to connect Qt TCP Socket with Boost Asio TCP socket. And what I found. Qt writes simple 12 bytes message to the Boost and in most situations Boost reads garbage. Even more Boost can crash. And my question is: who is so bad guy, Boost or Qt? You can find simple implementation of the problem in the attachment. Thanks. P.S. Problem is on Windows 7, on Linux or Mac OS I have no possibility to test...

2 2