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

Asio and ZeroMQ
by Matthias Vallentin 11 Oct '12

11 Oct '12

A while ago, Maciej Gajewski started an effort to use Asio to observe a ZeroMQ socket [1]. Based on his code, I put together a thin library that wraps the implementation details. Since other have requested a working example, here it is now at github: https://github.com/mavam/bmq Any feedback is highly appreciated. A basic usage example looks like this: #include <boost/asio/io_service.hpp> #include <bmq.h> int main() { boost::asio::io_service io; bmq::context ctx(1); bmq::component c(ctx, io); auto sink = c.add_sink(ZMQ_PAIR, "inproc://x"); c.subscribe(sink, [](bmq::message&& msg) { std::string str(static_cast<char*>(msg.data()), msg.size()); std::cout << str << std::endl; }); auto source = c.add_source(ZMQ_PAIR, "inproc://x"); bmq::message msg(const_cast<char*>("foo"), 3, nullptr); source->send(msg); // Execute message handler. io.poll(); return 0; } At this point, the library is really thin and only provides very rudimentary wrapping of ZeroMQ. In the future, I plan to extend it in order to facilitate applications that build on message-passing. The dataflow abstraction I envision is essentially a directed graph, where nodes represent components and edges communication links. 0mq provides the edges and the Asio handles asynchronous event processing at the component level. The motiviation is that this model lends itself well for scaling out distributed systems over large clusters. Matthias [1] http://permalink.gmane.org/gmane.network.zeromq.devel/9538

4 4

[Sandbox - endian] Why is endian still in sandbox?
by Nathaniel J Fries 07 Oct '12

07 Oct '12

A fairly novel (at least when put up against more intricate labours like asio, filesystem, and their like) project which appears to be finished and would be a very useful companion to existing libraries sits in the sandbox. Is there a reason for this?

3 3

[BGL] vecS for vertex container and vertex index adjustments
by Sergey Mitsyn 03 Oct '12

03 Oct '12

Hi all, I know that while using vecS for vertices one has no vertex iterator stability upon removing vertices. But I have a question if there exists something like vertex _index_ stability. The documentation says that indices for vertices are automatically adjusted so that they are still in contiguous range, but it is not specified how it is done. Is it okay to assume that if a vertex with an index I is removed, then vertices with indices < I have their indices unchanged, while vertices with indices > I have their indices decreased by one? The actual problem is removing all vertices meeting some condition. Is the following code ok? // traverse all vertices and remove those for which predicate // condition_to_remove_vertex returns true. // graph is adjacency_list<.., vecS, ...> vertex_iterator vi = vertices(graph).first, vi_end = vertices(graph).second; while (vi != vi_end) { if (condition_to_remove_vertex(vi, graph)) { vertices_size_type end_index = vertex_index[*vi_end] , vi_index = vertex_index[*vi]; remove_vertex_f(*vi, graph); // vi and vi_end are invalid --end_index; vi = vertices(graph).first + vi_index; vi_end = vertices(graph).first + end_index; // now vi and vi_end are valid again } else ++vi; } This way seems to be more effective than to start iteration again every time a vertex is removed. ------------ Sergey Mitsyn.

3 14

[Range] insert algorithm fails if target is a map
by Robert Jones 11 Sep '12

11 Sep '12

The title says it all really. The failure occurs because the insert algorithm expects the container to provide a 3-arg insert of the form container.insert( position, begin, end ); whereas map's, multimap's and set's insert method only takes two arguments... map.insert( begin, end ); Is this limitation by design? It would be easy to provide specialisations for maps, mmaps and sets, but that would not be a completely general solution. - Rob.

3 3

filesystem directory_iterator run-time error during construction after upgrading to OSX Lion
by Martin Searancke 04 Sep '12

04 Sep '12

I have just upgraded my Mac to Lion and code that worked fine under snow leopard is giving me a run-time exception when constructing a directory_iterator. The error I am getting is "malloc: pointer being freed was not allocated" The line in question that raises this error is: for ( directory_iterator itr( my_path ); itr != end_itr; ++itr ) taken directly from the example and working fine under windows. This is version 1.49 installed with MacPorts. Is this a known problem? I found some vague references to a similar problem in an earlier version of boost but no solution. I have confirmed that I only have 1 copy of the headers and libs on the system and in the correct path. The date stamp on the files matches the last time I did a macports update so this should be the matching library for the header. Please note that I am a real novice to Mac development and have only just started porting code from windows for less than a month. Thanks in advance, Martin

3 2

[Graph] compilation error under Windows but not under Linux
by Gaël de Chalendar 29 Aug '12

29 Aug '12

Hello, I have a compilation error under Windows (Visual C++ 2008) with a code that works well under Linux (gcc 4.6.1 and before). The compilation error is: =========== /FsaAccess16.tcc(833) : error C2784: 'std::pair<graph_traits<G>::in_edge_iterator,graph_traits<G>::in_edge_iterator> boost::in_edges(graph_traits<G>::vertex_descriptor,const boost::subgraph<Graph> &)'ÿ: impossible de d‚duire l'argument modŠle pour 'const boost::subgraph<Graph> &' … partir de 'FrCeaLic2m::Common::FsaAccess::selected_graph_types16::spareGraphType' C:\PROGRA~1\boost\BOOST_~1\boost/graph/subgraph.hpp(432)ÿ: voir la d‚claration de 'boost::in_edges' Z: \Projets\MoteurMultimedia\mm_common\src\common/FsaAccess/FsaAccess16.tcc(778)ÿ: lors de la compilation de la fonction membre '<Inconnu>' de la classe <Inconnu> z: \projets\moteurmultimedia\mm_common\src\common\fsaaccess\FsaAccessReader16.h(118)ÿ: voir la r‚f‚rence … l'instanciation de la classe modŠle 'FrCeaLic2m::Common::FsaAccess::FsaAccess16<graphType>' en cours de compilation with [ graphType=FrCeaLic2m::Common::FsaAccess::selected_graph_types16::spareGraphType ] z: \projets\moteurmultimedia\mm_common\src\common\fsaaccess\FsaAccessSpare16.h(35)ÿ: voir la r‚f‚rence … l'instanciation de la classe modŠle 'FrCeaLic2m::Common::FsaAccess::FsaAccessReader16<graphType>' en cours de compilation with [ graphType=FrCeaLic2m::Common::FsaAccess::selected_graph_types16::spareGraphType ] =========== The line that does not compile is boost::tie(iei,ie_end) = boost::in_edges(commonTarget,m_graph); The function being compiled is declared like that: template <typename graphType > std::pair< const typename boost::graph_traits<graphType>::vertex_descriptor, bool > FsaAccess16<graphType>::findEquivalentInRegister( dicoVertexType tempState ){ ... And here graphType, the type of m_graph is spareGraphType defined by: struct selected_graph_types16 { ... typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, dicoVertexCountProperty> spareGraphType; ... This is a cmake based project that I compile using qtcreator. I'm a Linux developer and I'm a little bit lost with VC outputs and tools under Windows... Regards, Gaêl -- Gael de Chalendar CEA LIST Centre de Fontenay-aux-Roses Laboratoire Vision et Ingénierie des Contenus (Vision and Content Engineering Laboratory) Bat. 38-2 ; 18, rue du Panorama ; BP 6 92265 Fontenay aux Roses Cedex ; France Tél.:01.46.54.80.18 ; Fax.:01.46.54.75.80 Email : Gael.D.O.T.de-Chalendar.A(a)T.cea.D.O.T.fr

2 2

Re: [Boost-users] asio HTTP Server 3 example memory leak
by admin＠thefireflyproject.us 25 Aug '12

25 Aug '12

2 1

eos_portable_archive for 1.49
by Paul Harris 13 Jul '12

13 Jul '12

Hi all, Does anyone know if eos_portable_archive is still actively used and maintained? It doesn't compile with boost 1.49, and before I try to fix it up, I was wondering if anyone else has fixed it up. cheers Paul

7 11

[bgl] depth_first_search does not compile. color_map howto?
by Joachim Faulhaber 04 Jul '12

04 Jul '12

Hi, When using visitors with the depth_first_search algorithm I can successfully compile and run this code: //========================================================= template<class Graph> class Visitor: public default_dfs_visitor { public: typedef typename graph_traits<Graph>::vertex_descriptor Vertex; void discover_vertex(Vertex v, const Graph& g)const {cout << v << " "; return;} }; void GLV_visit() { typedef adjacency_list<listS, vecS, directedS> GraphLV; GraphLV g; add_edge(0, 1, g); add_edge(0, 2, g); add_edge(1, 2, g); add_edge(1, 3, g); Visitor<GraphLV> vis; boost::depth_first_search(g, visitor(vis)); cout << endl; } BOOST_AUTO_TEST_CASE(graph_test) { GLV_visit(); } //========================================================= With a slightly different graph (listS instead of vecS for vertices) the same call of depth_first_search fails to compile with msvc-10. //========================================================= struct Int{ Int(): _value(0){} Int(int val): _value(val){} int _value; }; void GLL_visit() { typedef adjacency_list<listS, listS, directedS, Int> GraphLL; typedef graph_traits<GraphLL>::vertex_descriptor VertexLL; GraphLL g; Int val(42); VertexLL v0 = boost::add_vertex(g); VertexLL v1 = boost::add_vertex(g); g[v0] = Int(0); g[v1] = Int(1); add_edge(v0, v1, g); Visitor<GraphLL> vis; boost::depth_first_search(g, visitor(vis)); //compile errors } //========================================================= >From the tiny error message of 108 long verbose lines of internal graph template instantiations (see attachment) it seems that the compiler is unable to create a default color_map (but I might be wrong with this interpretation of the template jungle). 1. Do I need to provide a color_map parameter here? 2. If so, what is the simplest way to do that and provide an object of the appropriate type? I'd greatly appreciate a working code example. Examples and best practices for defining and handling external propery maps in general would be helpful. TIA, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 5

[statechart] history in the different state hierarchies
by Vlad Orlov 02 Jul '12

02 Jul '12

Hello everybody. I have a problem similar to the one described in the Statechart tutorial, but a little different. My state machine has two states (let's call them A and B) in the different state hierarchies and a third state C that can be transited to from either A or B. The transition from C must be done to either A or B, depending on where we came to C from. So I've decided to use the history. The difference between this problem and what's described in the tutorial is that A and B don't belong to the same composite state (they only belong to the same state machine). I can't simply declare "has_xxx_history" in the outer state like it's done in the tutorial. Here's what I've tried to do: #include <iostream> #include <boost/statechart/shallow_history.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/transition.hpp> namespace sc = boost::statechart; // events struct transfer_to_B : sc::event<transfer_to_B> {}; struct visit_C : sc::event<visit_C> {}; struct exit_to_history : sc::event<exit_to_history> {}; // forward declarations struct state_A; struct substate_A; struct substate_B; struct state_C; // state machine struct test_fsm : sc::state_machine<test_fsm, state_A> {}; // composite state A struct state_A : sc::simple_state<state_A, test_fsm, substate_A, sc::has_shallow_history> {}; struct substate_A : sc::simple_state<substate_A, state_A> { typedef boost::mpl::list < sc::transition<transfer_to_B, substate_B> , sc::transition<visit_C, state_C> > reactions; substate_A() { std::cout << "Entered A" << std::endl; } ~substate_A() { std::cout << "Exited A" << std::endl; } }; // composite state B struct state_B : sc::simple_state<state_B, test_fsm, substate_B, sc::has_shallow_history> {}; struct substate_B : sc::simple_state<substate_B, state_B> { typedef sc::transition<visit_C, state_C> reactions; substate_B() { std::cout << "Entered B" << std::endl; } ~substate_B() { std::cout << "Exited B" << std::endl; } }; // simple state C struct state_C : sc::simple_state<state_C, test_fsm> { typedef sc::transition < exit_to_history, sc::shallow_history<substate_A> > reactions; state_C() { std::cout << "Entered C" << std::endl; } ~state_C() { std::cout << "Exited C" << std::endl; } }; int main() { test_fsm fsm; fsm.initiate(); fsm.process_event(visit_C()); fsm.process_event(exit_to_history()); fsm.process_event(transfer_to_B()); fsm.process_event(visit_C()); fsm.process_event(exit_to_history()); } Unfortunately, this doesn't work as intended. The transition to history always leads to substate_A and never to substate_B: Entered A Exited A Entered C Exited C Entered A Exited A Entered B Exited B Entered C Exited C Entered A Exited A Can anyone please clarify if I've got something wrong or made a mistake somewhere? Is history supposed to work in the different state hierarchies?

2 2