- Boost-users - lists.boost.org

Missing something about Boost.Graph
by Dominique Devienne 28 Oct '15

28 Oct '15

We have a graph of relational tables, with the foreign keys being the edges of the graph. We're using boost::topological_sort() to sort the graph, and have struggled in the past with Boost.Graph. Recently we had cycles appearing in our graph, so I'm revisiting this code, and I think I must be missing something fundamental about Boost.Graph, because I get what I consider incoherent results. Here are the relevant code snippets. typedef std::pair<std::size_t, std::size_t> IndexPair; std::vector<IndexPair> edges; // fill edges with pairs of integers, in range [0, 111] (at the moment) using namespace boost; typedef property<vertex_color_t, default_color_type> GraphProperty; typedef adjacency_list<vecS, vecS, directedS, GraphProperty> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; Graph G(edges.begin(), edges.end(), edges.size()); size_t max_vrtx_index = 0; for (const auto& e : boost::make_iterator_range(boost::edges(G))) { size_t s = boost::source(e, G); size_t t = boost::target(e, G); max_vrtx_index = std::max(max_vrtx_index, s); max_vrtx_index = std::max(max_vrtx_index, t); } const auto G_vrtx_count = num_vertices(G); const auto G_edge_count = num_edges(G); if (G_vrtx_count != (max_vrtx_index + 1)) { std::cout << "Graph has " << G_vrtx_count << " vertices " "and " << G_edge_count << " edges, yet in reality " "our edges refer to at most " << max_vrtx_index << " vertices!" << std::endl; } This outputs: Graph has 1137 vertices and 1137 edges, yet in reality our edges refer to at most 111 vertices! How can num_vertices() and num_edges() return the same number? Why isn't num_vertices() returning 112 as I'd expect? I'm using 1.58. Thanks, --DD

2 2

[DLL] unclear how to specify calling convention for dll::import
by Konstantin Ivlev 27 Oct '15

27 Oct '15

Hello, I've just started using Boost.DLL in order to simplify loading of various WinApi functions exclusive to specific Windows versions, however, I've faced the issue (or may be it's just misunderstanding from my side). it's pretty well-known there are multiple calling conventions around - cdecl, stdcall, fastcall, etc. most of WinApi functions are in stdcall calling convention, while default one for MSVC 2015 is cdecl (unless compiler options are changed). I've read documentation on http://apolukhin.github.io/Boost.DLL/, as well as I've scanned source code a bit, but didn't find any avidence on how to specify calling convention of function I am importing. example from tutorial9 works just fine, as it uses timeGetTime function which has no arguments. however, if I modify example (see my code below copy-pasted from tutorial9) to import function with at least one argument or more (e.g. GetStdHandle) I receive the following debugger error: Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention. this indicates that Boost.DLL incorrectly interpreted stdcall function as cdeacl function that caused stack corruption. I've googled a bit about calling convention and boost, and found the following two definitions: #define BOOST_BIND_ENABLE_STDCALL #define BOOST_MEM_FN_ENABLE_STDCALL unfortunately adding them has no effect. if I add explicit __stdcall into the function typedef, then program no longer compiles #include <boost/dll/import.hpp> // for import #include <iostream> #include <windows.h> namespace dll = boost::dll; int main() { typedef HANDLE(GetStdHandle_fn)(DWORD nStdHandle); // function signature boost::function<GetStdHandle_fn> plugin = dll::import<GetStdHandle_fn>( // we import using C name, not alias! Using `import<>` "Kernel32.dll", // Windows dll "GetStdHandle" // function name ); std::cout << "timeGetTime() returned " << plugin(STD_OUTPUT_HANDLE) << std::endl; return 0; }

1 0

[signals2] connected signal not being called
by Glenn Ramsey 27 Oct '15

27 Oct '15

Hi, In a program I have a function connected to to a signal that is being called periodically. At a certain point the function inexplicably stops being called. Other functions that are connected to the same signal and same group are still being called at this time. As far as I am aware disconnect() has not been called and connection.connected() returns true and connection.blocked() returns false for this function. This seems very strange to me and I'm wondering if there is something that I have overlooked. It's not the sort of thing that could be reproduced with a simple example. What would be a good way to debug this? Glenn

2 2

Interest in a Boost.Chrono/Date library
by Vicente J. Botet Escriba 26 Oct '15

26 Oct '15

Hi, maybe some of you have already see the Howard Hinnant presentation at CppCOn2015 [1] about his new data-v2 library [2]. My prototype of Boost.Chrono/Date library ([3] ] was based on the Howard original library, but when we want to reach the maximum of performances we need to use a specific date class for each usage. This is what Howard explains in his marvelous presentation ans his tiny date library My post here wants to know if there is interest in a library providing what H.H. date library provides in Boost. Note that his data-v2 library yet doesn't provides as much as Boost.Date provides but IMHO it is much elegant and efficient. If there is enough interest, I will request you to do a first review of the H.H. Date-V2 library. Then once we have a consensus I will make my POC Chrono/Date library ready for review. H.H. Date-V2 is under MIT license, which IIRC is compatible with the Boost license. I don't know yet if would need to add this license, as my POC [3] is already a good starting point, nevertheless, I would like to know if there could be any issues about having the source under both licenses. Best, Vicente [1] https://www.youtube.com/watch?v=tzyGjOm8AKo [2] https://github.com/HowardHinnant/date [3] https://github.com/viboes/chrono_date/commits/master First commit Nov/2011 Last-Mars2014

2 2

[Log] linker errors after update from 1.57 to 1.59
by Glenn Ramsey 25 Oct '15

25 Oct '15

Hi, After updating a project to use Boost 1.59 from 1.57 I am getting link errors like this: Undefined symbols for architecture i386: "boost::log::v2_mt_posix::basic_formatter<char> boost::log::v2_mt_posix::parse_formatter<char>(char const*, char const*)", referenced from: boost::log::v2_mt_posix::basic_formatter<char> boost::log::v2_mt_posix::parse_formatter<char>(char const*) BOOST_LOG_DYN_LINK has been defined and the build works with 1.57. This is on OSX 10.10.5 with Xcode 6.4 and with command line builds using clang (Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)). Boost was built using this command line: ./b2 --prefix=$HOME/rp/boost-1_59_0 cxxflags="-stdlib=libc++ -arch i386 -mmacosx-version-min=10.7" linkflags="-stdlib=libc++ -arch i386 -mmacosx-version-min=10.7" --with-python --with-signals --with-thread --with-date_time --with-filesystem --with-regex --with-chrono --with-log link=shared architecture=x86 install What do I need to do fix this? Glenn

1 0

[BGL] adding an edge without modifying a graph?!
by Ireneusz Szcześniak 24 Oct '15

24 Oct '15

Hi, The subject sounds crazy, I know. But I need to add reverse edges so I can run a max-flow algorithm on my graph, and I would not like to modify the input graph. I can make a copy of the graph, modify it all right, run a max-flow algorithm, and discard the modified graph, but that would be inefficient. So I wonder whether someone could share some trick on how to do that, if this is possible. I was hoping to use boost::subgraph: create a root graph, create its subgraph, and then add reverse edges only to the root graph. Unfortunately, these edges also popped up in the subgraph. Thanks & best, Irek

2 3

[BGL] augmenting for a max-flow algorithm
by Ireneusz Szcześniak 24 Oct '15

24 Oct '15

Hi, I would appreciate it if someone could define the term "augmenting" used in the documentation of the max-flow algorithms: "First, the directed graph G=(V,E) that represents the network must be augmented to include the reverse edge for every edge in E." Does it simply mean that I need to add to the graph a reverse edge? In the documentation of the boykov_kolmogorov_max_flow algorithm it's stated point-blank: "The directed graph G=(V,E) that represents the network must include a reverse edge for every edge in E". Cool, so I know that I need to add the edge with the add_edge function. To use a max-flow algorithm I need to modify my input graph. So I guess "augmenting" means just "including/adding", right? Thanks & best, Irek

1 0

BGL, swapping two graphs can invalidate vertex descriptors?
by Paolo Bolzoni 24 Oct '15

24 Oct '15

Dear list, I had to fix a bug in a program of mine using the boost graph library. In the program I need to add and remove vertices quickly, so I used listS both for edges and vertices. Besides, I need to refer to vertices with special ids (that are integers), so I added to each vertex a integer and to the graph itself a map between the ids and the vertices. The interface ensures that when vertices are added and this data structures are updated properly. For reference I put the whole (minified) graph definition after the email. Now, I had a crash when using boost::out_edges in some part of the programs and not in others. After some debugging it really seems that it happens that the vertex descriptors, that are addresses to the vertices, change after a swap. Unfortunately I could not manage to make this behaviour in a small example so I am still unsure and I decided to ask here. It is possible that swapping two graphs (with listS as OutEdgeList and VertexList) invalidates the vertex descriptors? Yours faithfully, Paolo #include <boost/graph/adjacency_list.hpp> namespace graph_prop { struct vertex { int id{}; }; struct edge { int lenght{}; }; struct graph; } typedef boost::adjacency_list< boost::listS, boost::listS, boost::undirectedS, graph_prop::vertex, graph_prop::edge, graph_prop::graph > Graph; namespace graph_prop { struct graph { std::unordered_map<int, Graph::vertex_descriptor> ids{}; }; }

1 0

problems with linking...
by Witold E Wolski 24 Oct '15

24 Oct '15

In a project which vcproj files generated with cmake I am getting the following link error fatal error LNK1104: cannot open file 'libboost_date_time-vc120-mt-gd-1_59.lib' The generate link command (VS- project -> properties -> Linker -> command line) contains however: "C:\boost\boost_1_59_0\lib\boost_date_time-vc120-mt-gd-1_59.lib" both files are present in my boost binary build. Any idea why this mixup is taking place libboost_date_time vs. boost_date_time and how I can fix the problem? Best regards Witold -- Witold Eryk Wolski

2 2

[MSM] Solution for: fatal error C1202: recursive type or function dependency context too complex
by Mark Bartosik 21 Oct '15

21 Oct '15

I have had a major headache while using MSM eUML state transition tables, thankfully I've found a simple solution.First MSM and especially eUML are great, and that's why I persevered to find a solution. Here's the problem: Declaring a complex eUML state transition table may result in the compiler generating an error. BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((// row_1,// row_2,// ...// row_a,// row_b,// row_c,// // Eventually the Microsoft compiler VS2008,2010,2012,2015 will all explode with fatal C1202: recursive type or function dependency context too complex), transition_table ); I haven't tried with gcc. The solution is to break the state table in two smaller parts rather than one big table: BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((// row_1,// row_2,// ...), transition_table_part_1 ); BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((// row_a,// row_b,// row_c ), transition_table_part_2 ); typedef boost::mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table; // No error, even though it contains just as many rows [Waffle warning] I think that what's happening is that once the compiler has fully described the transition_table_part1 it unwinds what it is doing, it is able to unwind and 'bank' transition_table_part1 as just being a type in it's memory, and when it comes to generate transition_table via boost::mpl::join_view it just constructing the resulting type list from two sets of previously 'banked' types. This is I think why I can still nest a sub-state machine which is on the limit of the complexity of state transition table it can contain; even though nesting state machines recursively references state transition tables. Things that did not work: [ more waffle ] There are some other solutions that I tried before I had the Eureka moment. One was to try to hide a sub-state machine within a concrete class but that didn't work because the outer fsm needs to see the inner stt. Another way was to implement a sub-state machine as a concrete state (not fsm), and then add a process_event method on the class which delegated to a member fsm which was hidden from the outer fsm, I got this to work, but it did not solve the problem, and I had to abandon use of exit_pt_, although it may have brought down compile times. Another helpful advantage of this solution is that the memory required by the compiler is significantly reduced. Christophe:Would you consider adding the example above to the MSM documentation, I would suggest under: Chapter 4, Compilers / Performance, Compilers Corner Also under: Chapter 5, Questions Answers and Tips: Question: Why do I get "fatal C1202: recursive type or function dependency context too complex" Answer: Likely because a state transition table has become two complex. Split the state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts. Question: Why does my compiler generate a fatal out of memory fatal error. Answer: Likely because a state transition table has become two complex. Try and split the most complex state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts. - Mark Bartosik

1 0