- Boost-users - lists.boost.org

[Ref] unwrap_ref and TR1
by Krzysztof Żelechowski 14 Dec '11

14 Dec '11

The following code is valid: #if 1 #include <boost/ref.hpp> int const & (&b_unwrap_ref) (int const &) ((::boost ::unwrap_ref)); #endif The following code, however, is not (as of libstdc++ 4.5.1): #if 1 #include <tr1/functional> int const & (&tr1_unwrap_ref) (int const &) ((::std ::tr1 ::unwrap_ref)); #endif With the following diagnostic: > error: ‘unwrap_ref’ is not a member of ‘std::tr1’ So I started to ask myself: WTF? * It turns out that unwrap_ref did not make it to TR1, although reference_wrapper did. But why? * Because ref.hpp did not provide it when TR1 was formed? [1] Implication: * unwrap_ref (std:: reference wrapper) is a mismatch. #if 1 void test () { unwrap_ref (::boost ::cref (0)); unwrap_ref (::std ::tr1 ::cref (0)); // error: ‘unwrap_ref’ was not declared in this scope ::boost ::unwrap_ref (::std ::tr1 ::cref (0)); // error: error: invalid initialization of non-const reference } #endif Shouldn't we do something about it? Like, e.g., extend the scope of unwrap_ref to cover the corresponding standard class? This would at least allow expression #3. Chris ___ [1] <URL: https://svn.boost.org/svn/boost/!svn/bc/16384/trunk/boost/boost/ref.hpp >

1 0

challange to MPL gurus
by Robert Ramey 14 Dec '11

14 Dec '11

I am trying to implement concept checking for a couple of MPL concepts as part of a large project. I've having a heck of a time with some aspects of this. The example below illustrates one of the problems I'm having. The intent is to test the concept. for next<I>, the concept check is invoked recurrsively until the end of iteration is encountered. (I'm assuming it's a list in this test). But the is_end<false_> branch is always invoked leading to failure on both MSVC 9.0 and gcc 4.5.3 compilers I'll be quite impressed with anyone who can figure out how to make this work. Robert Ramey template<typename I> struct ForwardIterator { template<typename B> struct is_end {}; template<> struct is_end<false_> { typedef typename deref<I>::type t1; typedef typename next<I>::type t2; BOOST_CONCEPT_ASSERT(( ForwardIterator<t2> )); }; typedef typename boost::mpl::print< I >::type t1; typedef typename is_end< typename boost::is_same< boost::mpl::l_iter<boost::mpl::l_end>, I > > type; BOOST_MPL_ASSERT(( is_convertible< typename I::category, forward_iterator_tag > )); }; template<typename S> struct ForwardSequence { typedef typename end<S>::type t2; BOOST_CONCEPT_ASSERT(( ForwardIterator<t2> )); }; #include <boost/mpl/list.hpp> void test_list_sequence(){ BOOST_CONCEPT_ASSERT(( boost::mpl::ForwardSequence< boost::mpl::list<int, char> > )); }

4 15

Re: [Boost-users] Removing a vertex and adding another one with the same id causes segmentation fault?
by Alper Aydemir 14 Dec '11

14 Dec '11

The formatting went bad with the previous email. Sorry about that. Here it is once again. Hello, I'm using a labeled graph typedef boost::labeled_graph<boost::adjacency_list<boost::listS, boost::listS, boost::undirectedS, Room, RoomEdge>,std::string> MyGraph; which lets me access vertices with string ids. I add a vertex and set it's relevant fields this way: MyVertex u = boost::add_vertex(id, g); g[id].category = category; //crashes here g[id].vertex_id = id; Here id is an std::string. And remove them like so: // First we remove all edges from this vertex BGL_FORALL_VERTICES(v, g, MyGraph){ if (QString(g.graph()[v].vertex_id.c_str()).compare(roomIdToBeRemoved) == 0){ ve = v; BGL_FORALL_OUTEDGES(v, e, g, MyGraph) { ev.push_back(e); } } } foreach(MyEdge e, ev){ remove_edge(e,g); } // Then we remove the vertex itself remove_vertex(roomIdToBeRemoved.toStdString().c_str(),g); This so far seems to work. The trouble is, if I want to add a removed vertex once again with the same id, I get the following: Exception Type: EXC_BAD_ACCESS (SIGSEGV) while setting the fields of the newly added vertex (above commented "crashes here"). What might be the reason? I'm using boost functions for removing/adding things.

1 0

Error in accessing label of an edge, urgently need help.
by Amanullah Yasin 14 Dec '11

14 Dec '11

Hello, I want to put edge label but facing an error. Please share any better idea. Thanks in advance. YASIN ======================= My graph is: namespace boost { struct computable_object_t { typedef vertex_property_tag kind; }; } typedef boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::computable_object_t, plComputableObject*> > slVertexProperty; typedef boost::property<boost::edge_weight_t, slScoreValueType, boost::property<boost::edge_name_t, std::string>> slEdgeProperty; typedef boost::adjacency_list<boost::vecS, boost::listS, boost::bidirectionalS, slVertexProperty, slEdgeProperty> slGraph; slGraph graph; .... ... //Now i want to add edge name boost::property_map<slGraph, edge_name_t>::type labelmap = get(edge_name, graph); for(tie(ei, ei_end) = edges(graph); ei != ei_end; ++ei){ string label = "unknown"; put(labelmap, *ei, label); cout<<"\nUndirected s: "<<vertex_id[source(*ei, graph)] <<" T: "<<vertex_id[target(*ei, graph)]<<" LABEL: "<< get(labelmap,*ei); } ////////////But it gives me an error//////////////// E:\ProBT22\boost_1_46_1\boost/property_map/property_map.hpp(361): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const std::string' (or there is no acceptable conversion) 1> E:\ProBT22\boost_1_46_1\boost/pending/detail/property.hpp(21): could be 'boost::detail::error_property_not_found &boost::detail::error_property_not_found::operator =(const boost::detail::error_property_not_found &)' 1> while trying to match the argument list '(boost::detail::error_property_not_found, const std::string)' 1> MMHC\ResultAnalysis.cpp(558) : see reference to function template instantiation 'void boost::put<boost::adj_list_edge_property_map<Directed,Value,Ref,Vertex,Property,Tag>,Ref,boost::detail::edge_desc_impl<Directed,Vertex>,std::string>(const boost::put_get_helper<Reference,LvaluePropertyMap> &,K,const V &)' being compiled 1> with 1> [ 1> Directed=boost::bidirectional_tag, 1> Value=boost::detail::error_property_not_found, 1> Ref=boost::detail::error_property_not_found &, 1> Vertex=void *, 1> Property=boost::property<boost::edge_weight_t,slScoreValueType>, 1> Tag=boost::edge_name_t, 1> Reference=boost::detail::error_property_not_found &, 1> LvaluePropertyMap=boost::adj_list_edge_property_map<boost::bidirectional_tag,boost::detail::error_property_not_found,boost::detail::error_property_not_found &,void *,boost::property<boost::edge_weight_t,slScoreValueType>,boost::edge_name_t>, 1> K=boost::detail::edge_desc_impl<boost::bidirectional_tag,void *>, 1> V=std::string 1> ]

2 2

boost::hashes status
by Martin Dyring-Andersen 14 Dec '11

14 Dec '11

Hello, I've been using (parts of) the boost::hashes library for some time, and it seems to work quite well. Thanks Scott! A few changes are necessary to compile without errors and warnings Visual Studio 10 (see attached). I was wondering what the plans are for making it an official library? IMO it would be a very nice addition. As I recall, a suggestion was made to rename the library to boost::digest instead, to avoid confusion with boost::hash and the plural form. That seems sensible to me. -- Best regards, Martin Dyring-Andersen

2 1

Ambiguous boost::move
by Kelvin Chung 13 Dec '11

13 Dec '11

I'm having this compiler issue while trying to use boost::packaged_task (gcc, C++03, move emulation). When I try to compile, I get the following: src/KMBuilder.cpp:54: error: call of overloaded ‘move(boost::unique_future<long unsigned int>&)’ is ambiguous boost/include/boost/thread/detail/move.hpp:44: note: candidates are: typename boost::enable_if<boost::is_convertible<T&, boost::detail::thread_move_t<T> >, boost::detail::thread_move_t<T> >::type boost::move(T&) [with T = boost::unique_future<long unsigned int>] boost/include/boost/move/move.hpp:294: note: typename boost::move_detail::disable_if<boost::has_move_emulation_enabled<T>, T&>::type boost::move(T&) [with T = boost::unique_future<long unsigned int>] The offending line of code: futures.push_back(boost::move(taskResult)); // futures is a boost::container::deque Is there a way to force one version of boost::move over the other? If so, which one should I use?

3 2

Using unique_future in C++03, boost 1.47.0
by Kelvin Chung 13 Dec '11

13 Dec '11

I have a bunch of boost::packaged_task<unsigned long>, which I intend to execute on separate boost::threads. Before I do that, though, I want to insert each boost::unique_future<unsigned long> in a container as I make them. Given that I am using C++03 and boost 1.47.0 (boost 1.48.0 craps out over an ambiguous overload of boost::move), I have something like the following: std::deque<boost::unique_future<unsigned long>> futures; // std::deque<boost::thread> evalThreads; TODO for (…) { boost::packaged_task<unsigned long> task = …; // Create the tasks, one at a time boost::unique_future<unsigned long> taskResult = task.get_future(); // boost::thread taskThread(boost::move(task)); TODO // boost::unique_future and boost::thread can't be copied, but can be moved futures.push_back(boost::move(taskResult)); // evalThreads.push_back(boost::move(taskThread)); TODO } boost::wait_for_all(futures.begin(), futures.end()); // Now we can do stuff with futures The problem is that the code above is failing to compile, saying that /usr/include/c++/4.1.2/ext/new_allocator.h:104: error: passing ‘const boost::unique_future<long unsigned int>’ as ‘this’ argument of ‘boost::unique_future<R>::operator boost::detail::thread_move_t<boost::unique_future<R> >() [with R = long unsigned int]’ discards qualifiers I don't fully understand the problem, but I blame the move emulation. How do I fix this?

2 1

boost::shared_locks and boost::upgrade_locks
by Kelvin Chung 13 Dec '11

13 Dec '11

I'm trying to implement a read-write lock, and I was told to use boost::upgrade_lock. However, only one thread can have a boost::upgrade_lock, and everyone else gets blocked, so it's not much on the read end. (Correct me if I am wrong, but boost::upgrade_lock only waits if someone has exclusive, but someone with boost::upgrade_lock will cause everyone else to block) But reads are cheap in my case - I just need to use locks for a cache. So, suppose I have the following: class Cache { std::map<Input, Output> cache; boost::shared_mutex mutex; public: Output query(const Input& in); }; It would appear that the proper way to implement Cache::query() is as follows: Output query(const Input& in) { boost::shared_lock<boost::shared_mutex> readLock(mutex); if (cache.count(in) == 0) { readLock.unlock(); boost::unique_lock<boost::shared_mutex> writeLock(mutex); // Check to see if the result was added while waiting for lock if (cache.count(in) != 0) return cache[in]; cache[in] = compute_output(in); return cache[in]; } else { return cache[in]; } } Is this correct? Or maybe it should be this: Output query(const Input& in) { boost::shared_lock<boost::shared_mutex> readLock(mutex); if (cache.count(in) == 0) { readLock.unlock(); boost::upgrade_lock<boost::shared_mutex> rereadLock(mutex); // Check to see if the result was added while waiting for lock if (cache.count(in) != 0) { return cache[in]; } else { boost::upgrade_to_unique_lock<boost::shared_mutex> writeLock(rereadLock); cache[in] = compute_output(in); return cache[in]; } } else { return cache[in]; } } A side question is that if compute_output() is an expensive operation, should that be moved to the part between releasing the read lock and getting the write/reread lock?

5 9

Priority task queues using Boost.Asio and Boost.Thread
by Kelvin Chung 13 Dec '11

13 Dec '11

Suppose I have this abstract class Task like so: struct Task { virtual int doStuff() = 0; }; I then also have this: class CompositeTask : public Task { std::vector<Task> tasks; public: int doStuff() { for (std::vector<Task>::const_iterator it = tasks.begin(); it != tasks.end(); ++it) { it->do_stuff(); } } }; Now suppose that there is a point where I have a list of Tasks and I want to have them executed concurrently. To do so, I've leveraged Boost.Asio to create a thread pool task queue construct (via boost::asio::io_service). The next step beyond that is that I want to evaluate each of the tasks in CompositeTasks in parallel. I have a few questions about this: * One idea is to make a separate task thread for each CompositeTask. I'm under the impression that there is an absolute limit to the number of threads that I can make, which is determined by boost::thread::hardware_concurrency(). Is this true? If so, if the main Task queue has that many threads, would making a second task queue fail because it can't get more? * If I keep to one task queue (ie. throw all the Tasks in the CompositeTask to the main Task queue), then the possiblity exists of some kind of starvation (eg. the queue is full of CompositeTasks, and they are all blocking due to dependencies on Tasks in the queue). Is there a way to prioritize Tasks in the queue so that this doesn't happen?

3 2

Try-upgrade locking
by Kelvin Chung 13 Dec '11

13 Dec '11

Suppose I have a boost::upgrade_lock<boost::shared_mutex>. When I want to create the boost::upgrade_to_unique_lock<boost::shared_mutex> and upgrade to exclusive locking, this blocks until all the shared lock holders leave. However, it does not appear that there is a non-blocking version of this, unlike, say, making a boost::unique_lock<boost::shared_mutex> and passing in boost::try_to_lock. So what should I do in order to create my own "try-upgrade" lock? I'm trying to use it like so: boost::upgrade_lock<boost::shared_mutex> upgradeLock(mutex); ... if (...) { // Substitute for boost::upgrade_to_unique_lock<boost::shared_mutex>, but also with aspects of // boost::try_to_lock, basically my_upgrade_to_unique_lock<boost::shared_mutex> deferredWriteLock(lock); // Do stuff where it doesn't matter whether I have exclusive or not, while the readers leave if (!deferredWriteLock) deferredWriteLock.lock(); // Now we need exclusive // We have exclusive, do more stuff } // Back to regular upgrade_lock here

3 2