June 2010 - Boost - lists.boost.org

[endian] endian flip and endian domain
by vicente.botet 09 Jun '10

09 Jun '10

Hi, I think that I have found a good name that can be used instead of the swap_in_place: "flip". This recall the flip operation used in bitset exchanging the value of a bit. On the endian context this will exchange in place the endianess of a data from/to the native endianess. As the same data can be used with different endianess depending of the the context, the flip function needs a specific parameter, let me call this the endian domain. As the data to flip can containg part that are big and others that are little endian, we need to map all the leaveds of the tree associated to the data structure. The domain mill map staticaly the data to its endianess. For fundamental types this will be reduced to a single endian value, but for structures, the map will be a tree having as leaves endian types. This mapping allows us to separate the endian concern from the data itself in a clear way. For structures that have been adapted as fusion sequences, we can define flip_to/from functions that will do the the flip in a generic way. Of course the user could always overload the flips functions to provide its own implementation. I have started to play with this, and even if I'm not a metaprogramming expert, I have reached to have a prototype implementation that I need to polish a little bit more, before I share it with you. I will need your help later to make it much more elegant. Anyway, let me know what do you think of this design. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 19

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 09 Jun '10

09 Jun '10

<snip> >I have made an example which implements the UML state chart provided by Michael. > >well it does not compiles with VC9 :(. > >it compiles as fare as the explicit entry target state is a simple >state but does not if it is a composite sate (e.g.: a sub state >machine). There are several reasons to this and it took me a while to figure out what was happening. The first one is that there are 2 errors in the example: RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: RunningStateMachine::direct<RunningStateMachine_::Inner1> As you are directly entering RunningStateMachine, not Inner1. The second has to do with the fact that msm looks for states in the transition table. In particular, RunningStateMachine has: struct transition_table : mpl::vector< // Start Event Next Action Guard // +---------+-------------+---------+---------------------+----------------------+ a_row < InitialState , event4 , InitialState , &RunningStateMachine_::onEvent4 > // +---------+-------------+---------+---------------------+----------------------+ > {}; There is no Inner1 or Inner2 to be found, so you need to tell msm about them. Add in RunningStateMachine: typedef mpl::vector<Inner1,Inner2> explicit_creation; So now it should compile. But it doesn't because I think VC9 has a bug and seems to look for Inner1 not in RunningStateMachine 's table but in Inner1's, then complains not to find it. MinGW g++4.4 compiles the code fast and correctly. However, VC9 is not the only one with bugs, and if you add Inner1 into RunningStateMachine's table, it will not compile, so msm also has a bug and I simply forgot the case of a submachine being an explicit entry. You just happen not to notice it in this example. I attach you the corrected example in case you use g++ and do not need Inner1 in RunningStateMachine's transition table. So, we'll have to live with this restriction for the moment and I offer you an alternative solution. Replace the explicit entry by an entry point (from a design perspective, I find it better anyway). I attach you this solution too. HTH, Christophe

2 1

Re: [boost] [endian] endian flip and endian domain
by Dave Handley 09 Jun '10

09 Jun '10

Gottlob Frege wrote: > I think what I am saying is that, conceptually at least, the > endian-types come first, and the straight functions are built on top > of that (instead of the other way around as most are suggested). > Now, I wouldn't want that to impact performance, which is why I say > 'conceptually'. We can specialize the heck out of everything so that > performance wins, but I think the conceptual foundation is important. I disagree. If you have an endian type then I think you are coding in from the beginning a need for a copy in order to endian swap - even if the endian swap is a no-operation. Unless I'm missing something here. I also don't think this is bad. Remember that endian swapping happens once at the boundary of the code. It isn't something that is constantly changing type and we shouldn't be worried about the programmer losing track of what type the data is in imho. Of course, if someone can come up with a typed interface which doesn't enforce a copy then I may change my mind. Next, on naming, I think we should be very careful that we don't over-think the naming question. I'll ask a general question. What term does everyone use when talking about endian swapping? Certainly in my programming career I've never heard it called anything other than endian swapping. Also (and I know this shouldn't be taken as a definitive source) Wikipedia refers to the process of changing endianness as a byte swap. Shouldn't we use swap because that is what everyone knows the process of changing endianness as? That's my 2d, but I'm not wholly against another naming option. Dave

3 4

[mpl] #861 Detect nested template members with has_template_xxx
by Steven Watanabe 09 Jun '10

09 Jun '10

AMDG The patch attached to https://svn.boost.org/trac/boost/ticket/861 works with all the compilers I have to test with. It's fairly long, so I'm not including it here. Okay to commit? In Christ, Steven Watanabe

3 4

Bug Sprint daily update for Monday, June 7th
by Marshall Clow 09 Jun '10

09 Jun '10

As of 0800 Pacific time today, we had 958 open trac tickets. That is down by 30 from yesterday, and 31 since the start of the bug sprint. Great work, everyone! Thanks especially to Steven W, Andy W, and Viboes for all their work. Activity summary for yesterday: New tickets: 3 Modified: 38 Closed: 34 Reopened: 1 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: None -16 thread -12 Building Boost -2 date_time -2 GIL -1 asio -1 filesystem -1 function -1 fusion -1 iterator -1 quickbook -1 Documentation 1 circular_buffer 1 foreach 1 interprocess 1 intrusive 1 mpi 1 mpl 1 pool 1 program_options 1 serialization 1 Python 2 utility 2 build 5 Changed totals by author: <none> -25 anthonyw -11 djowel -6 az_sw_dude -2 bemandawes -1 bschaeling -1 chris_kohlhoff -1 dlwalker -1 hljin -1 speedsnail -1 agurtovoy 1 cnewbold 1 danielw 1 eric_niebler 1 jano_gaspar 1 matias 1 niels_dekker 1 no-maintainer 1 pdimov 1 ramey 1 witt 1 igaztanaga 2 danieljames 4 vladimir_prus 9 Changed totals by category: Bugs -17 Feature Requests -5 Patches 1 Support Requests 1 -- Marshall

3 4

[regex, xpressive] interesting(?) perf benchmark
by Eric Niebler 08 Jun '10

08 Jun '10

I'm always suspect of benchmarks, but I figured I'd post this anyway. http://astl.sourceforge.net/bench.7.html. It seems someone wrote a generic automata library and a regex engine on top of it, and compared its performance to boost.regex, xpressive, pcre, and greta. Of course, his library wins handily. (The purpose of benchmarking is to make yourself look good, right? ;-) He doesn't say that (a) his engine is a DFA, and he's comparing to NFAs; and (b) he's only implemented a tiny subset of regex features people would expect; e.g., no captures even, let alone backreferences: things that can be tricky or impossible to implement with DFAs. He also doesn't say what version of Boost he's using (tests run Nov. 2009) or whether he's using static or dynamic xpressive (probably dynamic; static can be ~15% faster). Anyway, it's not my intention to kick off yet another costly escalation in the regex war. God help me, I don't have the time. I post it here because I haven't come across a comparison of these four libraries by a third party before. Some quick observations: - I'm pleased that on the balance, xpressive fares well here relative to the other NFAs. In the end, though, not much separates best from worst. - All the NFA libraries seem to have large overhead that becomes very noticeable when matching short strings. I don't know why. - I'm gobsmacked that my VERY OLD library greta handily beats pcre, boost.regex /and/ xpressive on short matches. Failing to beat yourself in any perf benchmark is kind of embarrassing. - I'm tickled that for long matches, both xpressive and boost.regex (NFAs) beat his library (DFA). How'd that happen? - I find it interesting that both xpressive and boost.regex have large discontinuities in the chart at the bottom; the others don't. Huh. When more std library vendors start shipping regex libraries, I'll be interested in seeing this perf matrix expanded. -- Eric Niebler BoostPro Computing http://www.boostpro.com

10 22

Spam in ticket 865
by Jeremiah Willcock 08 Jun '10

08 Jun '10

There is a spam comment in <URL:https://svn.boost.org/trac/boost/ticket/865> that should be removed. -- Jeremiah Willcock

1 0

[asio] Race conditions detected with valgrind drd in example/http/server2
by Jorge Moraleda 08 Jun '10

08 Jun '10

When testing boost.asio (example/http/server2) for race conditions using valgrind drd, some errors are reported right after the first connection to the server is made. I am using Valgrind-3.6.0.SVN and gcc version 4.4.4 (Debian 4.4.4-4). This is an up to date Debian sid 64 bit system. To reproduce: g++ -l boost_thread -l boost_system /opt/boost/boost/doc/html/boost_asio/example/http/server2/*cpp valgrind --tool=drd ./a.out 127.0.0.1 31174 8 /tmp While it is running type "http://localhost:31174/main.cpp" in your browser (where main.cpp is a file in /tmp). Then several race conditions occur. These are the valgrind error messages: ==7737== drd, a thread error detector ==7737== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==7737== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==7737== Command: ./a.out 127.0.0.1 31174 8 /tmp ==7737== ==7737== Thread 4: ==7737== Conflicting load by thread 4 at 0x061875f0 size 8 ==7737== at 0x40DB72: boost::asio::detail::op_queue<boost::asio::detail::reactor_op>::front() (in /tmp/a.out) ==7737== by 0x417974: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation<boost::asio::detail::epoll_reactor> >&) (in /tmp/a.out) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x417D26: boost::asio::io_service::run() (in /tmp/a.out) ==7737== by 0x430358: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::call<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&, void const*) const (in /tmp/a.out) ==7737== by 0x42FF74: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&) const (in /tmp/a.out) ==7737== by 0x42FE1E: unsigned long boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (in /tmp/a.out) ==7737== by 0x42FD66: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > >::operator()() (in /tmp/a.out) ==7737== by 0x42EE79: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > > >::run() (in /tmp/a.out) ==7737== by 0x4E41F5F: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7737== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7737== Address 0x61875f0 is at offset 80 from 0x61875a0. Allocation context: ==7737== at 0x4C26FD1: operator new(unsigned long) (vg_replace_malloc.c:261) ==7737== by 0x43BDC8: __gnu_cxx::new_allocator<std::_List_node<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::allocate(unsigned long, void const*) (in /tmp/a.out) ==7737== by 0x43B72D: std::_List_base<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::_M_get_node() (in /tmp/a.out) ==7737== by 0x43AD64: std::list<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::_M_create_node(std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x43A0FC: std::list<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::insert(std::_List_iterator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> >, std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x439A77: boost::asio::detail::hash_map<int, boost::asio::detail::epoll_reactor::descriptor_state>::values_insert(std::_List_iterator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> >, std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x438B60: boost::asio::detail::hash_map<int, boost::asio::detail::epoll_reactor::descriptor_state>::insert(std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x43811B: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== Other segment start (thread 3) ==7737== at 0x4C2F283: pthread_mutex_lock (drd_pthread_intercepts.c:578) ==7737== by 0x40AC2B: boost::asio::detail::posix_mutex::lock() (in /tmp/a.out) ==7737== by 0x40D4CF: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock(boost::asio::detail::posix_mutex&) (in /tmp/a.out) ==7737== by 0x4380D4: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== by 0x40AF7A: boost::asio::detail::reactor_op::perform() (in /tmp/a.out) ==7737== by 0x41798B: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation<boost::asio::detail::epoll_reactor> >&) (in /tmp/a.out) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== Other segment end (thread 3) ==7737== at 0x4C2FE7F: pthread_mutex_unlock (drd_pthread_intercepts.c:631) ==7737== by 0x40AC45: boost::asio::detail::posix_mutex::unlock() (in /tmp/a.out) ==7737== by 0x40D500: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::~scoped_lock() (in /tmp/a.out) ==7737== by 0x438273: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== by 0x40AF7A: boost::asio::detail::reactor_op::perform() (in /tmp/a.out) ==7737== by 0x41798B: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation<boost::asio::detail::epoll_reactor> >&) (in /tmp/a.out) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== ==7737== Thread 3: ==7737== Probably a race condition: condition variable 0x8583c40 has been signaled but the associated mutex 0x61820f8 is not locked by the signalling thread. ==7737== at 0x4C283F9: pthread_cond_signal@* (drd_pthread_intercepts.c:736) ==7737== by 0x4119FE: void boost::asio::detail::posix_event::signal_and_unlock<boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex> >(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x4108F2: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::wake_one_idle_thread_and_unlock(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x40F1C2: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::wake_one_thread_and_unlock(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x40DA56: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::init_task() (in /tmp/a.out) ==7737== by 0x40B941: boost::asio::detail::epoll_reactor::init_task() (in /tmp/a.out) ==7737== by 0x4148D8: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::reactive_socket_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x414035: boost::asio::stream_socket_service<boost::asio::ip::tcp>::stream_socket_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x413893: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::stream_socket_service<boost::asio::ip::tcp> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40ADB8: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (in /tmp/a.out) ==7737== by 0x412B7E: boost::asio::stream_socket_service<boost::asio::ip::tcp>& boost::asio::detail::service_registry::use_service<boost::asio::stream_socket_service<boost::asio::ip::tcp> >() (in /tmp/a.out) ==7737== by 0x411B3A: boost::asio::stream_socket_service<boost::asio::ip::tcp>& boost::asio::use_service<boost::asio::stream_socket_service<boost::asio::ip::tcp> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== cond 0x8583c40 was first observed at: ==7737== at 0x4C27C59: pthread_cond_init@* (drd_pthread_intercepts.c:652) ==7737== by 0x417573: boost::asio::detail::posix_event::posix_event() (in /tmp/a.out) ==7737== by 0x419F07: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info::idle_thread_info() (in /tmp/a.out) ==7737== by 0x419FBC: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x417D26: boost::asio::io_service::run() (in /tmp/a.out) ==7737== by 0x430358: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::call<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&, void const*) const (in /tmp/a.out) ==7737== by 0x42FF74: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&) const (in /tmp/a.out) ==7737== by 0x42FE1E: unsigned long boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (in /tmp/a.out) ==7737== by 0x42FD66: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > >::operator()() (in /tmp/a.out) ==7737== by 0x42EE79: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > > >::run() (in /tmp/a.out) ==7737== by 0x4E41F5F: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7737== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7737== mutex 0x61820f8 was first observed at: ==7737== at 0x4C2EC6B: pthread_mutex_init (drd_pthread_intercepts.c:537) ==7737== by 0x40AB63: boost::asio::detail::posix_mutex::posix_mutex() (in /tmp/a.out) ==7737== by 0x410B72: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::task_io_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40F679: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40ADB8: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (in /tmp/a.out) ==7737== by 0x40DDDE: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>& boost::asio::detail::service_registry::use_service<boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor> >() (in /tmp/a.out) ==7737== by 0x417C48: boost::asio::io_service::io_service() (in /tmp/a.out) ==7737== by 0x416921: http::server2::io_service_pool::io_service_pool(unsigned long) (in /tmp/a.out) ==7737== by 0x437816: http::server2::server::server(std::string const&, std::string const&, std::string const&, unsigned long) (in /tmp/a.out) ==7737== by 0x43064D: main (in /tmp/a.out) ==7737== ^C==7737== ==7737== For counts of detected and suppressed errors, rerun with: -v ==7737== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 225 from 194)

1 1

[endian] views and conversions
by vicente.botet 08 Jun '10

08 Jun '10

Hi, I have pushed the endian typed approach a little more. Given an C/C++ builtin integer, we can see it as an endian with a given endianness using a cast or view operation. This operation doesn't do any conversion when its parameter is a fundamental (integer) type, but just let the user states that the integer stored in the variable has been stored with the given endianness. int b; Let me say that b contains an integer with big endian format (this has been done by reading from an external device, e.g.) The following expression as<big>(i) or endian_cast<big>(i) will see the i storage as a big endian integer holder. Now we can convert from big to native as follows int n; as<native>(n) = as<big>(b); as<endianness>(x) can be implemented as a function that return a endian reference to an integer with a specific endianness. Let me call this class endian_view. endian_view will define the assignment operator so the there is a conversion when both sides have the same endianness. In place conversion can be done as follows: as<native>(b) = as<big>(b); In order to support the in place version the assignement operator on endian_views, needs to check in addition if the reference integer is the same. But this check could be inefficient when we are converting a whole structure. The same operation can be overloaded for endian_views and do a in_place conversion in this case as<native>(as<big>(b)); can be read as: make the integer b (which is formatted with big endian format) have a native endian format. Just some more thougths that can grow on the endian forest. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

[msm] Nested submachines and explicit state entry
by Christophe Henry 08 Jun '10

08 Jun '10

Hi Michael, >As already stated in the documentation it is possible to have explicit >state entry into another submachine within a state machine. > >Is there a possibility to have a state machine, which has another >submachine with explicit state entry and that submachine has another >submachine with an initial transition. >I put that together in a picture and attached it. I hope then it gets >clearer what I want to do. >The picture shows just a simplified version of the overall state machine >and I discarded some other states, transitions and orthogonal regions. Starts becoming an interesting case ;-) Yes it should work. I tested with the same depth-level without any problem. What is not supported yet would be if your explicit entry was going into a substate of a submachine of a submachine, meaning you can only "cross" one submachine boundary. So your example is ok. >How do I have to declare the transition table and states in that case? A transition table is always declared inside a state machine, after the states have been declared. In my examples I always declare states inside the front-end but it is only for readability. In your case, you could declare the SM1 front-end, then inside its declaration add the one for RunningStateMachine, then inside RunningStateMachine the one for Inner1 and Inner2. After Inner1 and Inner2, the table for RunningStateMachine, then the table for SM1. something like: struct SM1_... { struct RunningStateMachine_... { struct Inner1_...; typedef msm::back::state_machine<Inner1_> Inner1; ... // add RunningStateMachine table }; typedef msm::back::state_machine<RunningStateMachine_> RunningStateMachine; // add SM1 table }; typedef msm::back::state_machine<SM1_> SM1; >Are there any restrictions regarding nested depth? Not in the library. I see just 2: - your patience while compiling - your compiler. At some point, it will probably get pissed off ;-) Regards, Christophe

2 2