June 2011 - Boost-users - lists.boost.org

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

[multi-index] Complex searches, multiple predicates, foreign keys
by dv 07 Jun '11

07 Jun '11

Hi, I stumbled upon this multi-index example: http://www.boost.org/doc/libs/1_46_1/libs/multi_index/doc/examples.html#exa… and I do not understand the gains in the second step. To sum up, the example wants to apply two predicates to the search - select elements with the given manufacturer, and select elements that fall in a certain price range. It does so by using one predicate in a first search (for example, finding all elements with the given manufacturer), then taking the range of search results, and copy it to another multi-index container (using pointers to avoid unnecessary deep copying of the elements). Then it performs a second search using the other predicate (in this example, the price range) to further narrow down the range of results. It is this copying and creating of the 2nd container that bugs me. Isn't this unnecessary? It implies O(n) steps to insert the search results, n being the number of results from the 1st search. Then, why use a second multi-index container? Why shouldn't I just use remove_copy_if() instead? it would make sense if copying the subset into a new multi-index container were faster than O(n), but I doubt that. What do you think? regards

2 1

BGL metric_tsp_approx time complexity?
by Anders Wallin 07 Jun '11

07 Jun '11

Hi all, I ran metric_tsp_approx on a number of TSPLIB problems and got the following graph: http://goo.gl/iGYsH This would indicate the time-complexity is V^2 (V is the number of cities/vertices). However the documentation [1] says O(E log V). A complete graph has O(V^2) edges, so the documentation would indicate metric_tsp_approx is O( V^2 log V ) (?) The heavy lifting in metric_tsp_approx is done by prim_minimum_spanning_tree, which the documentation [3] also lists as O(E log V). However I then go to [4] and see that for an adjacency matrix prim's algorithm runs in V^2. Confused, Anders [1] http://www.boost.org/doc/libs/1_46_1/libs/graph/doc/metric_tsp_approx.html [2] http://www.boost.org/doc/libs/1_46_1/libs/graph/test/metric_tsp_approx.cpp [3] http://www.boost.org/doc/libs/1_46_1/libs/graph/doc/prim_minimum_spanning_t… [4] http://en.wikipedia.org/wiki/Prim%27s_algorithm

2 3

Ranges to Collections
by John M. Dlugosz 07 Jun '11

07 Jun '11

I like "ranges". When I first read the introduction to the ideas that would become STL, I did not like the use of begin/end iterators. Primarily, there is a possibility of getting them mixed up and the proposed library was explicitly not robust in the face of being passed bad parameters, such as not belonging to the same collection or not having the end after the begin. This was in direct contrast to the code I was promoting, which stressed API design that prevented errors from being possible, and strongly checking for everything else. The fact that they are not "functional" was harder to grasp exactly at the time, but it bothered me "in my gut". When I read about the Boost Range library and the C++0x adoption of the range concept, I felt this to be a long sought improvement and would dramatically improve my use of STL. Suffice to say, I'm a fan of Ranges. In new work, and in refactoring and improving code, I expect ranges to be one of the pillars of improvement. I'm sad to see that the draft standard dropped most of the range stuff (presumably it needs Concepts) but left in the intrinsic for-each loop. Anyway, the concrete compiler I have to work with, Visual Studio 2010, doesn't include it. So Boost.Range to the rescue! Except... the standard containers like vector don't have constructors that take ranges. Consider something like: vector<string> retval (rangefunc | rangefilter); It really gets in the way to introduce a temporary variable of "some range type", but I see that the 'auto' feature comes to the rescue. I'm not used to having that available, so perhaps I'm over reacting. But, is there a way to bridge the gap? I take it patching the STL headers to add the missing constructors is frowned upon. But some syntactic sugar might get pretty close to that. First of all, what are people doing now? Maybe this has all be gone over before? I can see creating a derived class from each STL container. The sole purpose of that class is to have the range constructor, and then the resulting instance is used as the base class, passed somewhere or copied. So you might write, for the previous example: range_vector retval (rangefunc | rangefilter); and other code won't care about your derived class since it only existed district from the base class in order to add a constructor. In fact, a template might systematically do this to any class that has a constructor that takes two iterators: rangeit<vector<string>> retval (rangefunc | rangefilter); This is less than desirable in cases where you were not going to state the type. Say, a return statement or parameter, where you would ideally have an implicit conversion from a range to the collection: return (rangefunc | rangefilter); // give a "range" where collection is expected Could a helper template be written that has a simple name and doesn't need to be told the types involved? return range_to_collection (rangefunc | rangefilter); Perhaps this produces a temporary object that supports a templatized conversion operator, so it can continue when that is told the type desired. I can see a few approaches, depending on what the compiler would swallow. But, has anyone already done this? —John

2 3

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

07 Jun '11

Maybe you want make_vector() , make_list(). #include <vector> #include <list> #include <boost/range/algorithm.hpp> #include <boost/range/algorithm_ext/push_back.hpp> #include <boost/range/adaptor/reversed.hpp> // for test template<class T, class SinglePassRange> T make_container(const SinglePassRange& from) { T c; boost::push_back(c, from); return move(c); } template<class SinglePassRange> std::vector<typename SinglePassRange::value_type> make_vector(const SinglePassRange& from) { return make_container<std::vector<typename SinglePassRange::value_type>>(from); } template<class SinglePassRange> std::list<typename SinglePassRange::value_type> make_list(const SinglePassRange& from) { return make_container<std::list<typename SinglePassRange::value_type>>(from); } int main(int argc, _TCHAR* argv[]) { std::vector<char> vector1; vector1.push_back(1); vector1.push_back(2); vector1.push_back(3); std::list<char> list1; list1.push_back(1); list1.push_back(2); list1.push_back(3); auto vector2 = make_container<std::vector<char>>(vector1 | boost::adaptors::reversed); auto vector3 = make_vector(vector1 | boost::adaptors::reversed); auto vector4 = make_vector(vector1); auto list2 = make_container<std::list<char>>(list1 | boost::adaptors::reversed); auto list3 = make_list(list1 | boost::adaptors::reversed); auto list4 = make_list(list1); return 0; } > ------------------------------ > > Message: 2 > Date: Mon, 06 Jun 2011 11:00:29 -0500 > From: "John M. Dlugosz" <mpbecey7gu(a)snkmail.com> > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Ranges to Collections > Message-ID: <15775-1307376032-823667(a)sneakemail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > I like "ranges". When I first read the introduction to the ideas that would > become STL, I > did not like the use of begin/end iterators. Primarily, there is a possibility > of getting > them mixed up and the proposed library was explicitly not robust in the face > of being > passed bad parameters, such as not belonging to the same collection or not > having the end > after the begin. This was in direct contrast to the code I was promoting, which > stressed > API design that prevented errors from being possible, and strongly checking > for everything > else. The fact that they are not "functional" was harder to grasp exactly at > the time, > but it bothered me "in my gut". > > When I read about the Boost Range library and the C++0x adoption of the range > concept, I > felt this to be a long sought improvement and would dramatically improve my > use of STL. > > Suffice to say, I'm a fan of Ranges. In new work, and in refactoring and > improving code, > I expect ranges to be one of the pillars of improvement. I'm sad to see that > the draft > standard dropped most of the range stuff (presumably it needs Concepts) but > left in the > intrinsic for-each loop. Anyway, the concrete compiler I have to work with, > Visual Studio > 2010, doesn't include it. So Boost.Range to the rescue! Except... the > standard > containers like vector don't have constructors that take ranges. > > Consider something like: > vector<string> retval (rangefunc | rangefilter); > > It really gets in the way to introduce a temporary variable of "some range type", > but I > see that the 'auto' feature comes to the rescue. I'm not used to having that > available, > so perhaps I'm over reacting. > > But, is there a way to bridge the gap? > > I take it patching the STL headers to add the missing constructors is frowned > upon. But > some syntactic sugar might get pretty close to that. First of all, what are > people doing > now? Maybe this has all be gone over before? > > I can see creating a derived class from each STL container. The sole purpose > of that > class is to have the range constructor, and then the resulting instance is used > as the > base class, passed somewhere or copied. So you might write, for the previous > example: > range_vector retval (rangefunc | rangefilter); > > and other code won't care about your derived class since it only existed > district from the > base class in order to add a constructor. In fact, a template might > systematically do > this to any class that has a constructor that takes two iterators: > rangeit<vector<string>> retval (rangefunc | rangefilter); > > This is less than desirable in cases where you were not going to state the type. > Say, a > return statement or parameter, where you would ideally have an implicit > conversion from a > range to the collection: > return (rangefunc | rangefilter); // give a "range" where collection is > expected > > Could a helper template be written that has a simple name and doesn't need to > be told the > types involved? > return range_to_collection (rangefunc | rangefilter); > > Perhaps this produces a temporary object that supports a templatized conversion > operator, > so it can continue when that is told the type desired. I can see a few > approaches, > depending on what the compiler would swallow. But, has anyone already done > this? > > ?John > > >

4 6

C++ thread in BOOST
by Claude 06 Jun '11

06 Jun '11

Hi! I would like to use some c++2011 thread library functions in VC + + using BOOST thread. What is the equivalent of try_lock_for() (c++ timed_mutex) in BOOST timed_mutex? -- View this message in context: http://boost.2283326.n4.nabble.com/C-thread-in-BOOST-tp3577969p3577969.html Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

Using boost::asio
by Ram Sundar 06 Jun '11

06 Jun '11

Hi, I am trying to use boost::asio for a project where we currently use ACE. The way it currently works, the data that is passed between the server and client is preceded by a header with the data length. Currently with ACE when data is ready to be read at the socket, the handler function is invoked, and we invoke a ioctl with FIONREAD to read the number of bytes ready to be read and then allocate a buffer of that length to read the data. The reason we do this way is because the data may be sent in chunks. Internally we keep track of how much data we have received etc. I am at a loss to know how to do this using boost::asio. All the read methods expect a buffer where data will be read and it also needs the size of the buffer. Is there a way we get notified when data is ready to be read, and do similar operation. ie read the number of bytes available to read and then allocate buffers to read the data? Are there any other methods to accomplish the same? Thanks, Ram

4 4