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

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

29 Oct '15

Sorry this is a re-post because my email client had formatting enabled. 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

2 1

[Boost.Proto] implementing function call operators in expression trees
by Brook Milligan 29 Oct '15

29 Oct '15

I am trying to implement function call operators with Boost.Proto but cannot seem to figure out either how to set the expression trees up or how to evaluate them properly. The code below is simplified from the “checked calculator” example in the Proto documentation to focus on implementing a single identity function resulting from the Proto expression ‘identity(_1)’. The program prints the following function( terminal(9identity_) , terminal(0) ) result=0 [ expect 3 ] so I think the expression tree is correct. (I am, however, uncertain why the placeholder is reported as ‘terminal(0)’.) When the expression tree is evaluated with IdentityGrammar transform, the result is 0 not 3 as I would have expected if the placeholder value was used. The Proto documentation seems very thorough (at least after study), but is thin on the use of functions like this and is not helping me figure out the solution. I welcome any help that will point out the flaw(s) in this code for either setting up the expression tree or getting it evaluated correctly by calling the identity function with the correct argument. Thanks for your help. Cheers, Brook #include <boost/proto/proto.hpp> #include <boost/mpl/int.hpp> #include <boost/fusion/container/vector.hpp> #include <boost/fusion/container/generation/make_vector.hpp> namespace mpl = boost::mpl; namespace proto = boost::proto; namespace fusion = boost::fusion; template<typename I> struct placeholder : I {}; struct identity : proto::callable { typedef int result_type; int operator()(int a) const { return a; } }; struct identity_ {}; struct IdentityGrammar : proto::or_< proto::when< proto::terminal<placeholder<proto::_>> , proto::functional::at(proto::_state, proto::_value) > , proto::when<proto::terminal<identity_>, proto::_void> , proto::when< proto::function<IdentityGrammar, proto::terminal<proto::_>> , proto::and_< IdentityGrammar(proto::_child1) , identity(proto::_value(proto::_child1)) > > > {}; template<typename Expr> struct identity_expr; struct identity_domain : proto::domain<proto::pod_generator<identity_expr>, IdentityGrammar> {}; template<typename Expr> struct identity_expr { BOOST_PROTO_EXTENDS(Expr, identity_expr<Expr>, identity_domain) }; identity_expr<proto::terminal<identity_>::type> const identity = {{}}; identity_expr<proto::terminal<placeholder<mpl::int_<0> > >::type> _1; int main() { auto expr = identity(_1); proto::display_expr(expr); int result = IdentityGrammar()(expr,fusion::make_vector(3)); std::cout << "result=" << result << " [ expect 3 ]" << std::endl; return 0; }

1 0

Program Options: Omit positional arguments from help
by Florian Lindner 28 Oct '15

28 Oct '15

Hello, I have this piece of code: void getOptions(int argc, char *argv[]) { namespace po = boost::program_options; po::options_description desc("Artificial testing tool."); desc.add_options() ("help", "produce help") ("participant", po::value<std::string>(), "Participant Name"); po::positional_options_description pd; pd.add("participant", 1); po::variables_map vm; //po::store(po::parse_command_line(argc, argv, desc), vm); po::store(po::command_line_parser(argc, argv).options(desc).positional(pd).run(), vm); po::notify(vm); if (vm.count("help")) { std::cout << desc << std::endl; return; } } First question: Is the usage of po::store correct that way? I've found it somehwere on the internet but the documentation mentions no alternative parser call when using positional arguments. Main question: When using help it still displays --participant, albeit it's only a placeholder for the positional argument. Is there a way to hide a options or what is the correct way? Thanks, Florian

1 0

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