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

Re: [Boost-users] [statechart] Is it possible to have nested (sub)states in an asynchronous state machine?
by Andreas Huber 09 Jun '11

09 Jun '11

Hi [snip] > I started to > suspect that the statechart library does not support the > nesting of states > in an asynchronous state machine. Am I right or am I missing > something? Probably the latter: Asynchronous state machines should be able to deal with nested states just like synchronous ones. Please post a small but complete program that demonstrates the issue. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

Regex no longer builds with toolset=sun
by Will Mason 08 Jun '11

08 Jun '11

Hello, The last version of Boost that successfully builds on Solaris x86 32-bit with the Sun compiler (toolset sun) was version 1.43. Are there any plans to fix this toolset going forward? Thank you, Will Mason

6 10

[statechart] Is it possible to have nested (sub)states in an asynchronous state machine?
by Gurcan Gulesir 08 Jun '11

08 Jun '11

Hi, I am trying to implement an asynchronous state machine whose states contain substates. Since my compilation errors seem to be related to the statechart library (instead of directly to the code I wrote myself), I started to suspect that the statechart library does not support the nesting of states in an asynchronous state machine. Am I right or am I missing something? Upon trying any combination of boost::statechart::state and boost::statechart::simple_state as the super class of the top-level states and sub states, the typical compilation errors I received are like the following: 'deep_construct' is not a member of 'boost::statechart::simple_state<MostDerived, Context, InnerInitial, historyMode>::deep_construct_inner_impl_non_empty::deep_construct_inner_impl (const boost::intrusive_ptr<T>&, typename Context::inner_context_type::outermost_context_base_type&) [with InnerList = boost::mpl::list<robot::RobotSM::SCOUTING, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, MostDerived = robot::RobotSM::CONNECTED_WITH_OPERATOR, Context = robot::RobotSM::RobotSM, InnerInitial = robot::RobotSM::SCOUTING, boost::statechart::history_mode historyMode = (boost::statechart::history_mode)0u]::current_inner' RobotBehavior line 894, external location: /usr/include/boost/statechart/simple_state.hpp C/C++ Problem 'class boost::statechart::simple_state<robot::RobotSM::SAFE_TO_MOVE, robot::RobotSM::CONNECTED_WITH_OPERATOR, boost::mpl::list<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, (boost::statechart::history_mode)0u>' has no member named 'deferred_events' RobotBehavior line 360, external location: /usr/include/boost/statechart/simple_state.hpp C/C++ Problem 'class boost::statechart::state<robot::RobotSM::SAFE_TO_MOVE, robot::RobotSM::CONNECTED_WITH_OPERATOR, boost::mpl::list<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, (boost::statechart::history_mode)0u>' has no member named 'set_context' RobotBehavior line 50, external location: /usr/include/boost/statechart/state.hpp C/C++ Problem If nested states are intentionally not supported in current Boost.Statechart, is there a fundamental reason for this restriction? Or is it just not yet implemented as a feature of asynchronous state machines? Many thanks for your response, in advance. Best regards, Gurcan

1 0

More Boostcon videos available
by Marshall Clow 08 Jun '11

08 Jun '11

Sumant (Mondau): http://blip.tv/boostcon/toward-native-xml-processing-using-multi-paradigm-d… Justin (Tuesday): http://blip.tv/boostcon/intel-s-c-software-transactional-memory-compiler-an… Robert Stewart (Tuesday): http://blip.tv/boostcon/spirit-qi-in-the-real-world-5254335 ( I'm not going to be able to keep up this pace, btw...... ) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[Thread] unresolved typeref token for 'boost.detail.win32._SECURITY_ATTRIBUTES' using /clr
by Daniele Barzotti 08 Jun '11

08 Jun '11

Hi, I try to build my C++ library with the /clr option to make it visible to managed world. I get a linker error: warning LNK4248: unresolved typeref token (01000027) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run I found the ticket#2226 (https://svn.boost.org/trac/boost/ticket/2226) which say that 'Boost thread does not work with managed C++ when statically linked.' How can I solve this issue? I need to link it dynamically? Regards, Daniele.

1 0

BGL edge iteration questions
by David Doria 08 Jun '11

08 Jun '11

1) When is it appropriate to use adjacency_list directly vs using directed_graph and undirected_graph? 2) I am trying to iterate over the edges of a directed_graph: http://codepad.org/jO3rJLtF In the first method I tried: typedef boost::graph_traits < Graph >::out_edge_iterator out_edge_iterator; std::pair<out_edge_iterator, out_edge_iterator> outEdges = boost::out_edges(v1, g); , memory addresses seem to be output instead of vertex ids. In the second method: typedef boost::property_map<Graph, boost::vertex_index_t>::type IndexMap; IndexMap index = get(boost::vertex_index, g); , vertex ids are output, but I didn't specify if I wanted in edges or out edges? When using adjacency_list directly, I used to have to specify boost::bidirectionalS: typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS> Graph; Is something like that required when using directed_graph? Thanks, David

2 2

Assigning vertex properties
by David Doria 08 Jun '11

08 Jun '11

I am trying to assign names to vertices. I made a typedef boost::property<boost::vertex_name_t, std::string> VertexProperty; and tried to set a label for vertex 0 in two ways: A) g[0] = "Vertex0"; and B) boost::property_map<Graph, boost::vertex_name_t>::type value = boost::get(boost::vertex_name_t(), g); boost::put(value, 0, "Vertex0"); Neither compiles. In the second one, the problem with this: boost::put(value, 0, "Vertex0"); is that "0" is not the right type - I guess the vertex IDs should be vertex_descriptor's instead of ints? How do I get the descriptor of vertex #0 ? Here is the full code: http://codepad.org/7VYELJan Thanks, David

3 3

Re: [Boost-users] Ranges to Collections
by 乔志强 08 Jun '11

08 Jun '11

> ------------------------------ > > Message: 5 > Date: Tue, 07 Jun 2011 09:25:51 -0500 > From: "John M. Dlugosz" <mpbecey7gu(a)snkmail.com> > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Ranges to Collections > Message-ID: <31696-1307456755-210504(a)sneakemail.com> > Content-Type: text/plain; charset=GB2312 > > On 6/6/2011 9:31 PM, ??? qiaozhiqiang-at-leadcoretech.com wrote: > > Maybe you want make_vector() , make_list(). > > > > template<class T, class SinglePassRange> > > T make_container(const SinglePassRange& from) > > { > > T c; > > boost::push_back(c, from); > > return move(c); > > } > > I think it would be better to make use of the two-iterator form of the > constructor rather > than calling push_back. That way it can allocate storage for all elements in > advance if > the kind of range allows for finding the difference easily. > > { > return T (from.begin(), from.end()); > } > > I guess your way optimizes for the case where it needs to slowly traverse the > range in > order to find the end() first. I suppose boost::push_back does something > similar if it > can, but it still constructs as zero size and then resizes. ////////////////////////////////////////////////////// std::vector<T> a; // this line does not allocate storage a.insert(a.end(),boost::begin(from) ,boost::end(from));// boost::push_back(c, from) call insert, this will allocate storage only once if it can. std::vector(begin, end) does not know any range, But boost known more range detail, so you should use boost, and boost should has this function. And you should not call from.begin(), from.end(), you should call boost::begin(from), boost::end(from) > > > template<class SinglePassRange> > > std::vector<typename SinglePassRange::value_type> make_vector(const > SinglePassRange& from) > > { > > return make_container<std::vector<typename > SinglePassRange::value_type>>(from); > > } > > The make_container needs to be told the exact container type in the call, and > your > make_vector et al. is a different name for each possible container. I would > think you > could use a template template argument and pass in the container species only, > and have it > obtain the value_type for itself. I think that would be good enough, as the > details of the > value types is the hard part. > > But, I speculate that a simple expression could figure out the complete type > by itself via > using a templatized conversion operator. ////////////////////////////////////////////////////////// auto v = make_vector(a_range); make_vector() is good friend of AUTO, but templatized conversion operator not. So we need both.

1 0

Dijkstra example
by David Doria 08 Jun '11

08 Jun '11

I tried to modify this example: http://www.boost.org/doc/libs/1_34_0/libs/graph/example/dijkstra-example.cpp to create the graph in a clearer fashion: http://codepad.org/DDKs45oe However, I now get compiler errors inside dijkstra_shortest_paths.hpp Can anyone see where I have gone wrong? Also, I don't really understand the "distances and parents" output - I just want to know the shortest path between two vertices. In fact I don't even see the start and end vertices specified in the original example? Thanks, David

3 4

First Boostcon videos available....
by Marshall Clow 08 Jun '11

08 Jun '11

Keynote: http://blip.tv/boostcon/hans-boehm-threads-and-shared-variables-in-c-0x-key… Chris Kohloff (Monday): http://blip.tv/boostcon/thinking-asynchronously-designing-applications-with… Hartmut (Monday): http://blip.tv/boostcon/phoenix-v3-an-overview-5250984 -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1