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

[filesystem] directory_iterator and filter in 1.56.0
by Braden McDaniel 10 Sep '14

10 Sep '14

This sort of thing worked in Boost 1.55.0: #include <boost/filesystem.hpp> #include <boost/range.hpp> #include <boost/range/adaptor/filtered.hpp> struct pred { bool operator()(const boost::filesystem::directory_entry & dirent) const { return true; } }; int main() { const auto dirent_range = boost::make_iterator_range(boost::filesystem::directory_iterator("/"), boost::filesystem::directory_iterator()); const auto filtered_dirent_range = boost::adaptors::filter(dirent_range, pred()); } Not so in 1.56.0 [output from Apple's clang 3.4]: boost/concept_check.hpp:210:9: error: no viable conversion from 'boost::single_pass_traversal_tag' to 'boost::forward_traversal_tag' Y y = x; ^ ~ The full error output is much more verbose and I can provide it if desired; but the above is the gist of the situation, as I understand it: directory_iterators are SinglePass iterators; filter operates on ForwardTraversal iterators; and the SinglePass iterator cannot be converted to the ForwardTraversal one. Is this situation deliberate or an unintended side effect? Is there some similarly succinct means of filtering a file/directory listing? -- Braden McDaniel <braden(a)endoframe.com>

1 0

Re: [Boost-users] [context] Compiling error with context and bind
by José 10 Sep '14

10 Sep '14

3 2

[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