- Boost-users - lists.boost.org

[Graph] edge_range() with hash_setS as OutEdgeList in adjacency_list
by Ignacy Gawedzki 04 Mar '09

04 Mar '09

Hi, The following issue seems to have been discussed on this list a while ago, but nothing seems to have changed since and I was usable to find a proper answer so far. The edge_range() function uses std::equal_range() to extract a pair of iterators to the edges of interest. The problem lies in the fact that according to the SGI STL documentation, std::equal_range() requires the entries to be sorted (although I found no explicit mention of that in the standard). With hash_setS as OutEdgeList in adjacency_list, the entries are obviously not sorted, and std::equal_range() must not be used. While it's easy to write an edge_range_custom() function that would call the equal_range() method instead of the global function, nothing can be done to prevent the use of the original edge_range() by other library code like bidirectional_graph_helper_with_property::get_parallel_edge_sublist(). These overloaded methods are called from within remove_edge() which apparently causes trouble with hash_setS. I tried myself to overload the original edge_range(), for the case where hash_setS is used, but the solution is far from elegant and it feels like something be better done upstream. What do you think about that? Shouldn't the equal_range() method be used directly instead of std::equal_range() in any case? Thanks for your help. Ignacy -- /* This is not a comment */

1 0

workaround ideas?
by Noah Roberts 04 Mar '09

04 Mar '09

This may be a little OT but as it applies to metaprogramming and ideas from the book I thought it the best place to ask. On pgs 191/2 of the MPL book (section 9.5) is a set of ideas meant to introduce the inherit_linearly metafunction. There are some things I want to do that suggested this was actually the better way to go for me. So I implemented something like the following: struct empty {}; template < typename FIELD, typename CDR > struct rec : CDR { typename FIELD::type value; rec() : value() {} }; template < typename VEC > struct generate_record //: boost::mpl::inherit_linearly< VEC, boost::mpl::inherit< rec<pl::_2>, pl::_1> >::type : boost::mpl::fold< VEC, empty, rec< pl::_2, pl::_1> > {}; I implemented a getter function like so: template < typename FIELD, typename CDR > typename FIELD::type & get(rec< FIELD, CDR > & r) { return r.value; } Now, minus the "field" concept this seems to be exactly the same basic thing. The field concept is something I need for what I'm working on that currently, for this test, just has a type in it. I create a "record" like so: typedef generate_record< boost::mpl::vector<field1, field2, field3> >::type test_record; When I print the type I end up with: "rec<field3,rec<field2,rec<field1,empty> > >" and in main attempt to access it: test_record tr; get<field1>(tr) = 3; This works fine in comeau and I'd expect it to work anywhere but MSVC++ 8 doesn't like it. It says that the FIELD param is ambiguous and could be field1 (what I specified in the call) or field3 (the first field on the inheritance tree). The error text is exactly: 1>e:\dev_workspace\experimental\record_generation\record_generation\main.cpp(78) : error C2782: 'FIELD::type &get(rec<FIELD,CDR> &)' : template parameter 'FIELD' is ambiguous 1> e:\dev_workspace\experimental\record_generation\record_generation\main.cpp(58) : see declaration of 'get' 1> could be 'field3' 1> or 'field1' I'm calling this a compiler bug at this point. I suspect many here have had to deal with this, since it's basic template usage, and might know a workaround. Or maybe you see something I've done incorrectly.

2 4

boost logging or tracing library?
by Archie14 04 Mar '09

04 Mar '09

I was wandering - is there any support in boost for logging or tracing? If not, may be you can offer suggestions for the library that had been successfully used in production?

2 1

uploaded Channel - a lib for (distributed) message passing and event dispatching to boost vault
by Yigong Liu 04 Mar '09

04 Mar '09

Hello there, I just upload a updated version of my Channel library to Vault under Main/"Distributed Computing". This version contains some update for Channel to work with the latest boost distributions and change to boost license, since there are several requests for me to update and upload to Vault. A brief description: Channel procides name space for distributed message passing and event dispatching. Its major components (message IDs, routing algorithms...) are configurable as template parameters. As a namespace shared by peer threads, channels support publish/subscribe scope control, message filtering, and translation.. Thanks Yigong

1 0

[asio] sync receive_from with timeout
by Stephan Menzel 04 Mar '09

04 Mar '09

Is the subject Jehova enough for you? ;-) Great. Well, I haven't raised the subject so far but I'd certainly like to do so now. For years now I am not only a user but also an admirer of boost asio. Something that has always puzzled me however is, why a timeout functionality which is something very common and essential for sync IO just doesn't seem to be there. I think there are cases where syncronous IO is a better way to go and no async approach is sensible. In my case this is a collection of static functions that do UDP communication and therefore have to be sync because I just want them to be able to return and throw exceptions and be able to be called from anyone at any time. As always when I stumble across the asio/timeout problem I start googling around. When people raise the topic here they are usually pointed to an answer Chris Kohlhoff gave to someone asking that: http://lists.boost.org/Archives/boost/2007/04/120339.php ... which is good for tcp and works alright even though in my opinion it leaves the question why it has to be so compilicated to do something so basic. IMHO sync IO is all but pointless without a timeout. Anyway, I started to turn this into a UDP version and ended up with something very similar: inline void set_result(boost::optional<boost::system::error_code>* a, boost::system::error_code b) { a->reset(b); }; template <typename MutableBufferSequence> void udp_read_with_timeout(boost::asio::ip::udp::socket& sock, int tmo, boost::asio::ip::udp::endpoint &endpoint, const MutableBufferSequence& buffers) { boost::optional<boost::system::error_code> timer_result; boost::asio::deadline_timer timer(sock.io_service()); timer.expires_from_now(boost::posix_time::seconds(tmo)); timer.async_wait(boost::bind(set_result, &timer_result, _1)); boost::optional<boost::system::error_code> read_result; sock.async_receive_from(buffers, endpoint, boost::bind(set_result, &read_result, _1)); sock.io_service().reset(); while (sock.io_service().run_one()) { if (read_result) timer.cancel(); else if (timer_result) sock.cancel(); } if (*read_result) throw boost::system::system_error(*read_result); }; So now I started to go ahead with that but I had to notice two things. First, the performance impact is massive to a point that forces me to reconsider. Second, when I use that in a multithreaded environment the whole thing seems to block in some threads randomly. I have made test program where I have multiple threads using that method, just sending an UDP request to a server and waiting for an answer using this function. In one thread everything is slow but continously running. In more than one thread it blocks for up to 5 or 6 seconds every few (10-20) runs for no visible reason. In my scenario all those threads share a socket protected by a mutex so if one of them blocks all will be halted. So I come to think this is not a good way to handle the problem. Does anyone have some thoughts on that? May this be a bug in asio (1.38) or perhaps in my function? Or is there a better way to do sync UDP IO with a timeout functionality? Cheers... Stephan

3 12

BGL: is it safe to store vertex_descriptors?
by Cory Riddell 04 Mar '09

04 Mar '09

Is it safe to store vertex descriptors? Does adding a new vertex / edge ever renumber existing vertices? (I know removing does this) Say I have a class to represent a state from the USA. class State { ... }; and I have a bunch of instances: State california, oregon, nevada, hawaii, ...; I want a graph with a vertex for each state and an edge for each border: typedef adjacency_list<vecS, vecS, bidirectionalS> Graph; Graph graph; I build my graph like this: Graph::vertex_descriptor v_california = add_vertex(graph); Graph::vertex_descriptor v_oregon = add_vertex(graph); Graph::vertex_descriptor v_nevada = add_vertex(graph); Graph::vertex_descriptor v_hawaii = add_vertex(graph); ... add_edge(v_california, v_oregon, graph); add_edge(v_california, v_nevada, graph); add_edge(v_nevada, v_oregon, graph); ... To associate each State instance with a vertex, I make a map: map<State, Graph::vertex_descriptor> state_to_vtx_map; state_to_vtx_map[california] = v_california; state_to_vtx_map[oregon ] = v_oregon ; state_to_vtx_map[nevada ] = v_nevada ; state_to_vtx_map[hawaii ] = v_hawaii ; Now I can find all the states Nevada has a border with by doing this: Graph::vertex_descriptor v = state_to_vtx_map[nevada]; tie(begin, end) = out_edges(v, g); (please assume that I didn't store v_nevada from above) Is my state_to_vtx_map safe? Since a delete can totally renumber everything, I don't think it is safe. What's the correct way of associating a vertex with a State instance? Thanks, Cory

1 0

Compile error with QNX compiler
by Kito Berg-Taylor 04 Mar '09

04 Mar '09

I am using the QNX 6.4.0 development environment (based on gcc 4.2.4) to compile boost_thread-static-mt from boost 1.38, and I am getting the following errors. I was wondering if someone could tell me whether this is a compiler problem or a problem with boost. I should mention that I don't get the same error with gcc4 or mingw-gcc4. I have the latest boost from svn, but I'm unable to test that on this compiler because I'm still sorting through other build problems there. cd /path_to_build/build.qnx/Core/LIB_MISSIONPLANNER && /path_to_qnx/qnx640/host/linux/x86/usr/bin/qcc -Vgcc_ntox86 -lang-c++ -w1 -I/path_to_build/Externals/boost_1_38_0 -o CMakeFiles/MISSIONPLANNER.dir/CommTCP.cpp.obj -c /path_to_build/Core/LIB_MISSIONPLANNER/CommTCP.cpp In file included from /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:33, from /path_to_build/Externals/boost_1_38_0/boost/archive/detail/iserializer.hpp:64, from /path_to_build/Externals/boost_1_38_0/boost/archive/detail/interface_iarchive.hpp:23, from /path_to_build/Externals/boost_1_38_0/boost/archive/detail/common_iarchive.hpp:20, from /path_to_build/Externals/boost_1_38_0/boost/archive/basic_text_iarchive.hpp:31, from /path_to_build/Externals/boost_1_38_0/boost/archive/text_iarchive.hpp:23, from /path_to_build/Core/LIB_MISSIONPLANNER/Connection.hpp:19, from /path_to_build/Core/LIB_MISSIONPLANNER/CommTCP.hpp:6, from /path_to_build/Core/LIB_MISSIONPLANNER/CommTCP.cpp:1: /path_to_build/Externals/boost_1_38_0/boost/serialization/factory.hpp:37: error: template declaration of 'T* boost::serialization::factory' /path_to_build/Externals/boost_1_38_0/boost/serialization/factory.hpp:37: error: 'va_list' is not a member of 'std' In file included from /path_to_build/Externals/boost_1_38_0/boost/archive/detail/iserializer.hpp:64, from /path_to_build/Externals/boost_1_38_0/boost/archive/detail/interface_iarchive.hpp:23, from /path_to_build/Externals/boost_1_38_0/boost/archive/detail/common_iarchive.hpp:20, from /path_to_build/Externals/boost_1_38_0/boost/archive/basic_text_iarchive.hpp:31, from /path_to_build/Externals/boost_1_38_0/boost/archive/text_iarchive.hpp:23, from /path_to_build/Core/LIB_MISSIONPLANNER/Connection.hpp:19, from /path_to_build/Core/LIB_MISSIONPLANNER/CommTCP.hpp:6, from /path_to_build/Core/LIB_MISSIONPLANNER/CommTCP.cpp:1: /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp: In member function 'void* boost::serialization::extended_type_info_typeid<T>::construct(unsigned int, ...) const': /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:96: error: 'va_list' is not a member of 'std' /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:96: error: expected `;' before 'ap' /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:97: error: 'ap' was not declared in this scope /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:100: error: 'factory' was not declared in this scope /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:100: error: expected primary-expression before ',' token /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:102: error: expected primary-expression before ',' token /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:104: error: expected primary-expression before ',' token /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:106: error: expected primary-expression before ',' token /path_to_build/Externals/boost_1_38_0/boost/serialization/extended_type_info_typeid.hpp:108: error: expected primary-expression before ',' token cc: /path_to_qnx/qnx640/host/linux/x86/usr/lib/gcc/i386-pc-nto-qnx6.4.0/4.2.4/cc1plus error 1 compiler identifies itself as gcc 4.2.4: kito@Vostok:~$ ntox86-g++ --version ntox86-g++ (GCC) 4.2.4

1 0

I Can't Compile The QuickStart Example
by Fagner Patricio 04 Mar '09

04 Mar '09

Hello!! I'm new in the list, I from Brazil, so, sorry about my english :) I have a problem, I am try to compile the QuickStart Python Example on ubuntu 8.04 using the 1.34 library version, this is the result: fagner@fagner-desktop:/usr/share/doc/libboost-doc/examples/libs/python/example/quickstart$ sudo bjam toolset=gcc --verbose-teste test --debug-configuration notice: found boost-build.jam at /usr/share/doc/libboost-doc/examples/libs/python/example/quickstart/boost-build.jam notice: loading Boost.Build from /usr/share/boost-build notice: loading site-config.jam from /etc/site-config.jam notice: loading user-config.jam from /usr/share/boost-build/user-config.jam notice: using gcc libraries :: <toolset>gcc-4.2 :: /usr/bin /usr/lib /usr/lib32 /usr/lib64 notice: using gcc archiver :: <toolset>gcc-4.2 :: /usr/bin/ar warning: toolset gcc initialization: can't find tool windres warning: initialized from notice: using rc compiler :: <toolset>gcc-4.2 :: /usr/bin/as error: Unable to find file or target named error: '/boost/python//boost_python' error: referred from project at error: '.' fagner@fagner-desktop:/usr/share/doc/libboost-doc/examples/libs/python/example/quickstart$ What's my mistake? -- Fagner Patrício João Pessoa - PB Brasil

2 1

Re: [Boost-users] Tag dispatching
by Hicham Mouline 04 Mar '09

04 Mar '09

> ----- Original Message ----- > From: "Ovanes Markarian" <om_boost(a)keywallet.com> > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Tag dispatching > Date: Wed, 4 Mar 2009 14:12:09 +0100 > > Hicham, > > please see my comments below: > > On Wed, Mar 4, 2009 at 1:54 PM, Hicham Mouline <hicham(a)mouline.org> wrote: > > > Hello, > > > > I have a question about tag dispatching (for e.g. the std::advance() > > function in the std lib, as described for instance in > > http://www.boost.org/community/generic_programming.html#tag_dispatching) > > > > 1. The call to > > detail::advance_dispatch(i, n, category); > > I don't understand. category is a type not an object, it should be > > category(), right? > > > typename *iterator_traits<InputIterator>::iterator_category* category; > detail::advance_dispatch(i, n, *category*); > > here is no typedef used, so category is an instance of iterator_category. In > the template context you have to prefix it with typename keyword. Using: > > typename *iterator_traits<InputIterator>::iterator_category* category(); > > declares a function, which returns iterator_category, but does not create a > class instance. ah yes of course. I misread the typename as typedef, thanks. category is an auto instance. Can it be also written also as a temporary etail::advance_dispatch(i, n, iterator_traits<InputIterator>::iterator_category() ); > > 2. If I am correct, > > the tags are empty structs which I assume allows modern compilers > > (g++4, msvc8/9, intel) to optimize away the creation of that category > > object ? > > This is compiler dependent. ISO C++ 03 standard requires an instance of an > empty type to be at least 1 byte big. To check if that happens read the > documentation to the corresponding compiler. > > 3. If i am still correct, I have a tag which has no members except 1 static > > function that returns void. > > Would that optimization still apply? > > Applies the same as in 2. Whether the compiler prints sizeof(myType) as 1byte or something else has no bearing on whether it doesn't create an instance at runtime, right? need to read their docs (though it's quite hard to see where for g++ for e.g.) thanks very much, regards,

2 1

[BGL] Structure for BFSvisitor is in header file (visitor & property confusion)??
by Trevor Bain 04 Mar '09

04 Mar '09

I have my graph working with BFS, and a BFSvisitor. But, I don't want the BFSvisitor to be in the header file. Since, it is, I have to declare properties I want to use in the visitor, but then I have to pass them in in the constructor for the class that contains the graph and the visitor structure ... Here is my visitor (in .hpp): /* ... other code */ /*! Structure for creating BFSvisitor * * The property maps are being assigned in the constructor for the * Ann object - I don't know how inneficient of a method that is. * i.e. if I should be using references. */ struct propagate_node : public boost::base_visitor<propagate_node> { // getting the dynamically created VoltageMap boost::property_map<Digraph, vertex_voltage_t>::type voltmap; boost::property_map<Digraph, vertex_input_t>::type inputmap; boost::property_map<Digraph, vertex_output_t>::type outputmap; typedef boost::on_discover_vertex event_filter; /* * This is a functor For Breadth First Visit. */ template <class Vertex, class Digraph> void operator()(Vertex v, Digraph& G) { boost::graph_traits<Digraph>::out_edge_iterator ed; // getting the dynamically created VoltageMap && InputMap double volt = boost::get(voltmap, v); bool in = boost::get(inputmap, v); bool out = boost::get(outputmap, v); // mapping sigmoid (don't apply sigmoid to input/output layers) if (in == false && out == false) { // justify this sigmoid ??? volt = 1/(1+pow(MYEXP,-volt)); boost::put(voltmap, v, volt); } if (v != *vertices(G).first) { for ( ed = boost::out_edges(v, G).first; ed != boost::out_edges(v, G).second; ed++) { boost::put( voltmap, target(*ed, G), get(voltmap,target(*ed,G))+get(boost::edge_weight,G,*ed)* volt); } } } } prop; /* ... other code */ So in the c'tor I have to do (in .cpp): /* ... in initializer list */ VoltageMap(get(vertex_voltage_t(), net)), InputMap(get(vertex_input_t(), net)), OutputMap(get(vertex_output_t(), net)), /* ... other code */ prop.voltmap = VoltageMap; prop.inputmap = InputMap; prop.outputmap = OutputMap; to pass my properties from the graph to the visitor ... there has to be a better way to do this. How can I put the visitor definition into the .cpp, and only declare it in the .hpp?

2 2