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

Re: [Boost-users] re alization of Last Recently Used cache with boost::multi_index
by Joaquin M Lopez Munoz 04 Mar '09

04 Mar '09

Hi Pavel, pavel5 wrote: > > I am trying to realize class for strings caching using boost::multi_index. > [...] > My class works without any problem, but i want to have template class, for > easily type of key and value selection. I modified my source: > [...] > After modification, gcc compiler prints for line: > > LRUCacheItems::nth_index<0>::type& hash_index=cache.get<0>(); > > many errors:[...] > Replace the offending line with typename LRUCacheItems::nth_index<0>::type& hash_index=cache.template get<0>(); Note the extra "typename" and also the "template" keyword between "cache." and "get<0>()". After templatizing your LRUCache, the expression happens to be in a so-called dependent context, and turns out you've got to help the compiler figure it out right (i.e. disambiguate from some other interpretations theoretically possible in the given context). Learn more about this issue at http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=388 Hope this helps, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo -- View this message in context: http://www.nabble.com/realization-of-Last-Recently-Used-cache-with-boost%3A… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

boost::bind used with boost shared_ptr
by Kevin Ludwig 04 Mar '09

04 Mar '09

Hi, I've recently been making more use of boost::bind, and I coded the following, which I thought would work: class A { public: void reset () {} }; typedef std::map<int, boost::shared_ptr<A> > map_type; map_type m; std::for_each (m.begin(), m.end(), boost::bind(&A::reset, boost::bind(&map_type::value_type::second, _1))); but fails to compile. Next I tried this: std::for_each (m.begin(), m.end(), boost::bind(&A::reset, boost::bind(&boost::shared_ptr<A>::get, boost::bind(&map_type::value_type::second, _1)))); Which works and is fine (I guess). I just wonder why the first syntax is not supported? boost::shared_ptr is supposed to behave like a pointer (and here it seems that it does not). -- Kevin

2 3

[enable_shared_from_this] My derivation of enable_shared_from_this wants to be templated
by Rob Currey 04 Mar '09

04 Mar '09

Here's some code based upon the example at : http://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/enable_shared_from_this… class X { public: X() { }; }; template<class X> class Y: public enable_shared_from_this< Y<X> > { public: shared_ptr< Y<X> > f() { return shared_from_this(); } }; typedef Y<X> templatedY; int main() { shared_ptr<templatedY> p(new Y<X>); shared_ptr<templatedY> q = p->f(); assert(p == q); assert(!(p < q || q < p)); // p and q must share ownership } compiles with: $ gcc -o test -I/usr/local/include/boost-1_38 -lstdc++ -L/usr/local/lib -lboost_system-gcc41-mt test.cpp test.cpp: In member function âboost::shared_ptr<Y<X> > Y<X>::f()â: test.cpp:13: error: there are no arguments to âshared_from_thisâ that depend on a template parameter, so a declaration of âshared_from_thisâ must be available test.cpp:13: error: (if you use â-fpermissiveâ, G++ will accept your code, but allowing the use of an undeclared name is deprecated) Any resolution (other than the -fpermissive hack) TIA (my skilz with shared_ptr<> are somewhat lacking ...)

2 1

[iterators ]bug?
by bismuth＠list.ru 04 Mar '09

04 Mar '09

There is probably a bug in boost::iterators library. boost::transform_iteartor degrade stl iterator_category. There is a code below, illustrating a problem(using VS2008 c++ compiler): --------------------- #include <stdio.h> #include <tchar.h> #include <vector> #include <boost/iterator/transform_iterator.hpp> #include <boost/static_assert.hpp> struct Tr1: std::unary_function<unsigned, unsigned> { unsigned operator()(unsigned a)const { return a; } }; int _tmain(int argc, _TCHAR* argv[]) { typedef std::vector<unsigned>::iterator some_ra_iterator_t; typedef boost::transform_iterator<Tr1, some_ra_iterator_t> tr_iter_t; BOOST_STATIC_ASSERT (( boost::is_convertible < std::iterator_traits<some_ra_iterator_t>::iterator_category, std::random_access_iterator_tag >::value )); BOOST_STATIC_ASSERT (( ! boost::is_convertible < std::iterator_traits<tr_iter_t>::iterator_category, std::random_access_iterator_tag >::value )); BOOST_STATIC_ASSERT (( boost::is_same < std::iterator_traits<tr_iter_t>::iterator_category, boost::detail::iterator_category_with_traversal < std::input_iterator_tag, //?! boost::random_access_traversal_tag > >::value )); return 0; } ---------------------

2 1

[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