December 2011 - Boost-users - lists.preview.boost.org

no thread pool?
by Jeff Graham 15 Dec '11

15 Dec '11

Hello, I do not see a thread pool in current boost. Has one never been accepted? Thanks.

2 1

[gil] Project Link
by Dan Bloomquist 15 Dec '11

15 Dec '11

I have put my adventure with gil on the web, this is just the start. If I have any stuff that needs attention about gil, I'd like to hear it. I'm thinking this will help others that have not started with gil yet. <http://lakeweb.net/test/codeproject.html> Best, Dan.

2 1

Re: [Boost-users] [Units] Temperature conversion problem
by Pieter 14 Dec '11

14 Dec '11

>>>> If 'f' is 212ÂºF, why, when converting it to ÂºC, do I end up at 117 and change? Is this really what we should expect? It seems that this very simple use case produces unexpected, and to a casual user wrong, results. I understand the need for complexity but it seems to show up very early in the user experience. >>> >>> Because a temperature change of 212ÂºF is equal to a temperature change of 117.778ÂºC = (5/9)*212. What would you expect the following to do: > > >> [ snipped a very complete response ] > >> Hi Matthias, > > Sorry, I didn't explain myself very well. I was merely surprised that quantities of temperature are, by default, temperature differences not absolute temperatures. With my rusty engineering hat on, I'd have expected quantities of temperature to be absolute so they're consistent with the published literature. I think of temperature differences as needing explanation such as outputting a Celsius temperature difference as Âºâˆ†C (delta ÂºC, ÂºdC, ...) rather than expressing a temperature difference with just ÂºC. Operating under the principle of least surprise, I found the default temperature behavior surprising, that's all. I don't know how useful temperature difference by itself really is but I'd guess it's less common than absolute temperatures or normalized temperatures though differences are useful, for example, in temperature gradients. >Don't mean to come across as prickly - there was just a lengthy debate on this topic during review. Basically, while the first order "principle of least surprise" is probably for temperatures to be absolute, this would make quantities of temperature an anomalous special case relative to all other quantities and would immediately cause problems when someone wanted, e.g., to implement something like the Planck radiation law, etc... In any case, we do appreciate feedback and try to incorporate suggestions for improvements wherever possible. >Cheers, >Matthias Dear Matthias, In the example given by you earlier: quantity<fahrenheit::temperature> f(32*fahrenheit::temperature()); quantity<celsius::temperature> c(0*celsius::temperature()); std::cout << f+quantity<fahrenheit::temperature>(c) << std::endl; std::cout << quantity<celsius::temperature>(f)+c << std::endl; would give different outputs 32+32 = 64 and 0+0 = 0 if the temperature were to be interpreted as being absolute. As far as I see it, it is in fact not ‘the order of conversion, but rather the scale that is used to do the addition in is what matters: in the Fahrenheit scale, taking twice the absolute temp. means something different than taking twice the absolute temperature in the Celsius scale (due to the affine relation between the scales). This does not make it meaningless to allow such additions (or other arithmetic operations). To give an example: take Plank’s radiation law which computes radiation of a body as a function of the temperature T in K, which is of the form (for appropriate constants a1 and a2): B(T) = a1*(1-exp(a2*T))^-1 As arithmetic is not allowed on absolute temperatures, my implementation would have to define T as a relative temperature, something like (in admittedly non-compiling 'code'): quantity<intensity> BodyRadiation(const quantity<si::temperature>& T) { // define a1 and a2 here return a1*(1/(1-std::exp(a2*T))); } Suppose the radiating body is at room temperature which I measure using my thermometer on the wall as 20.0 degrees Celsius. When I would define this as a relative temperature: quantity< celsius::temperature> TRoomInCelcius(20.0); and plug it into the radiation law: Intensity = BodyRadiation(quantity<si::temperature>(TRoomInCelcius)) This would give wrong results (without any warning) as the value T = 20K would be used unintentionally. I know it is the intent of the library to emphasize safety over convenience but I fail to see a problem with my abstraction here, while I don't regard this safe behavior. To get correct results I would need to define my room temperature as being absolute: quantity< absolute<celsius::temperature> > TRoomInCelcius (20.0); then translate it into an absolute temperature in K: quantity<absolute< si::temperature> > TRoomInK(TRoomInCelcius); and then ‘somehow’ translate this into a relative temperature to be plugged into the model, maybe like: quantity<absolute<si::temperature> > TZero(0*si::kelvin) ; quantity<si::temperature> T(TRoomInK – TZero); Intensity = BodyRadiation(T) which is far from elegant of course. Core of the matter is that I need the temperature to be converted using the ‘absolute’ notion, while I need it to be interpreted as ‘relative’ to be able to use it in the radiation law. This while the underlying numerical value of the ‘relative’ and ‘absolute’ temperature is the same and in both cases represents the same measured value. If arithmetic on the absolute type was allowed, this could all be avoided as the model could be specified in ‘absolute’ temperature – I don’t really understand why you say that would not make sense. I am not sure whether there is an elegant solution to allow this in natural manner. Maybe conversion for units with affine relations between scales should only be allowed to be explicitly done in either the absolute or relative manner, which could possibly also relieve the need for two different 'types' of temperature; as the example shows a single measurement can have both 'relative' and 'absolute' interpretations in the current system depending on the context in which it is used and the type of conversion that the context requires. Does this make any sense to you? Kind regards, Pieter

1 0

b-tree merge
by Jeff Ramsey 14 Dec '11

14 Dec '11

As an example, I've the following b-tree model with each node containing tag/value pairs. The tree indicates precedence (or priority), with the root being highest, down to the leaves as lowest (but this is application specific). I want to merge a new tree section into the parent, with the new section containing potentially common tag/value pairs all the way down to the node just above a leaf node (a completely duplicate new tree section would just not be merged). E.g. Existing tree (tag,value) pairs indicated: A,0 ,----------,----|--------, B,1 B,2 B,3 ,------|------, C,1 C,2 New tree to merge: A,0 | B,3 ,------|------, C,1 C,2 Final merged tree: A,0 ,----------,----|--------------, B,1 B,2 B,3 ,------|------, ,-----------, C,1 C,2 C,1 C,2 Question: is there a boost solution to this b-tree merge, and if not any suggestions? Thanks.

1 0

[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

Boost matix question from a newbie
by boostnewbie 13 Dec '11

13 Dec '11

Hello, I want to use the boost matrices, and I have examples how to deal with that. But now, I want to store those matrix in a std-Array or an std-list. To do this, I must be able to name the type of for example a 3X3 matrix. I mean I nbeed an expressione similar to std::vector<matrix<double>> trafos; but I don´t know how to say that the matrix is a 3X3 type. Thanks in advence Egon -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-matix-question-from-a-newbie-tp418… Sent from the Boost - Users mailing list archive at Nabble.com.

3 2

shared_ptr to object in stl set container?
by Galen 13 Dec '11

13 Dec '11

Hi, -- I'm trying to use shared_ptr in a stl set, but am having trouble with find() Any help? Documentation on this seems hard to find. -- Also, are the overloaded < and == useful or correct here? thanks! Output is: ------------------ 0 adding neighbor 1 0 adding neighbor 2 1 adding neighbor 0 2 adding neighbor 1 0's neighbors 1 has 1 neighbors 0 2 has 1 neighbors 1 NOT WORKING is 1 a neighbor of 0? 0 is 0 a neighbor of 1? 0 Code below: ------------------- #include<set> #include<iostream> #include<boost/shared_ptr.hpp> using namespace std; //use typedef instead in actual code #define NodePtr boost::shared_ptr<Node> // TODO: should this extend shared_ptr? class Node { private: int id; set<NodePtr> neighbors; public: Node() { } Node(int newID) { id = newID; } ~Node() { } int getID() { return id; } int addNeighbor(NodePtr newNode) { int newID; newID = newNode->id; // if not already a neighbor, add if (!isNeighbor(newID)) neighbors.insert(newNode); } set<NodePtr> getNeighbors() { return neighbors; } bool isNeighbor(int searchID) { set<NodePtr>::iterator it; // check if this neighbor already in list NodePtr searchNode(new Node(searchID)); it = neighbors.find(searchNode); // if not found, add to neighbors if (it == neighbors.end()) { return false; } //else return true; } //overload == for find() bool operator== (NodePtr otherNode) { cout << "==: " << otherNode->id << " " << id << endl; return (otherNode->id == id); } //overload < in case we want to sort bool operator< (NodePtr otherNode) { return (id < otherNode->id); } }; int main() { // the nodes are pointers to Node objects NodePtr n0(new Node(0)); NodePtr n1(new Node(1)); NodePtr n2(new Node(2)); cout << n0->getID() << " adding neighbor " << n1->getID() << endl; n0->addNeighbor(n1); cout << n0->getID() << " adding neighbor " << n2->getID() << endl; n0->addNeighbor(n2); cout << n1->getID() << " adding neighbor " << n0->getID() << endl; n1->addNeighbor(n0); // cout << n2->getID() << " adding neighbor " << n0->getID() << endl; // n2->addNeighbor(n0); cout << n2->getID() << " adding neighbor " << n1->getID() << endl; n2->addNeighbor(n1); set<NodePtr> neighbors = n0->getNeighbors(); set<NodePtr>::iterator NB; int id = n0->getID(); cout << id << "'s neighbors" << endl; for (NB = neighbors.begin(); NB != neighbors.end() ; NB++) { set<NodePtr> neighborsList = (*NB)->getNeighbors(); cout << (*NB)->getID() << " has " << neighborsList.size() << " neighbors" << endl; cout << (*neighborsList.begin())->getID() << endl; } // http://www.engr.sjsu.edu/wbarrett/SortFind.htm cout << "NOT WORKING" << endl; cout << "is 1 a neighbor of 0? " << n0->isNeighbor(1) << endl; cout << "is 0 a neighbor of 1? " << n1->isNeighbor(0) << endl; }

6 11

Re: [Boost-users] Boost-users Digest, Vol 2933, Issue 5
by Marat Abrarov 13 Dec '11

13 Dec '11

Hi, Rory. > Is there a reason io_service::run does not set an appropriate error on the > passed boost::system::error_code object when this is encountered? Certainly > it seems like an error case and would help circuital circumstances such as > my own. With current behavior of asio::io_service we can continue working with io_service after it was stopped by calling asio::io_service::reset(). It's like pause on io_service. It's not often used feature but it is nice to know that such behavior is possible. Also note that invocation of handlers is done only within threads that executes asio::io_service::run (run_one, poll, poll_one - http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/overview/core/thre…) When io_service switches to the "stopped" state asio::io_service::run have to exit as fast as possible. When io_service is already in the "stopped" state asio::io_service::run have to exit immediately. So if io_service is already in stopped state before any user thread calls asio::io_service::run how can Asio pass "appropriate error" to asynchronous completion handlers? IMHO, current design of Asio is very clear. Regards, Marat Abrarov.

2 1

Re: [Boost-users] incompatible serialization format of boost::property_tree between 1.44 and 1.48 (Robert Ramey)
by kpzhang 13 Dec '11

13 Dec '11

Hi Robert, os: windows 7 compiler: visual studio 2008 sample code: #include <iostream> #include <string> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/json_parser.hpp> int main() { std::string str; { std::stringstream sstr; boost::property_tree::ptree pt; char a= '\0'; pt.put("a",a); boost::property_tree::write_json(sstr, pt); str = sstr.str(); std::cout << str << std::endl; } { std::stringstream sstr(str); boost::property_tree::ptree pt; boost::property_tree::read_json(sstr, pt); char a = '\1'; std::cout << (int)pt.get("a",a) << std::endl; } return 0; }

1 0

Request for change on Solaris platform
by Leo Carreon 13 Dec '11

13 Dec '11

Hi, I have just discovered that the Apache Standard C++ Library (stdcxx4) is now available in both Solaris 10 U10 and Solaris 11. Would it be possible to add stdcxx4 as a standard library option for Solaris on the next Boost release? Kind regards, Leo

1 0

[BGL] Default-constructibility of vertices
by Kelvin Chung 13 Dec '11

13 Dec '11

Suppose I have a class hierarchy, like so: struct Foo { virtual Output doSomething(const Input& in); }; class CompositeFoo { std::vector<Foo*> fooList; // Use your favorite smart pointer standin for Foo* here public: Output doSomething(const Input& in); }; Now, suppose I have a functor: class Functor { Foo* foo; Input input; // assume Input is copyable public: Output operator()() { foo->doSomething(input); } }; Now, the structure of doSomething() calls leads to a DAG structure with Functor as the vertices. What I want to do is create a graph with BGL that shows that structure, before topologically sorting it and doing other stuff with it. However, it would appear that the vertices of the graph (which I would assume to be of type boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, Functor>) must be default-constructible, which Functor is clearly not. Is there a nice workaround to this without changing the vertex type to Functor* (again, use your favorite smart pointer standin for Functor* here)?

2 1

[boost] [review] [Local] Review Result - ACCEPTED
by Jeffrey Lee Hellrung, Jr. 13 Dec '11

13 Dec '11

Local is ACCEPTED into Boost. After following the lively Local review discussion several weeks ago, and reviewing the discussion a second (and sometimes third) time, I have come to the above conclusion. There was quite a bit of passion on both the sides of "aisle", and thus, obviously, no decision I make would be well-received by all. Let me start by summarizing the main arguments against including Local in Boost: (a) Local functions are not very useful, at least in the presence of existing alternatives (e.g., namespace functions and Boost.Phoenix). (b) Local is really a portability library for C++03 presenting an imperfect emulation of features readily available in C++11. (c) Local's interface is primarily macro-based, making code ugly and difficult to read. In my opinion as the review manager, a sufficient number of individuals in the discussion found the library "useful" to address (a) (sometimes with additional positive adverbs); indeed, at least a couple individuals have shared positive experiences with real-world use. Namespace functions require one to move code to somewhere other than where one may prefer to have it, and often requires a significant amount of boilerplate when binding local variables. Aside from any perceived issues with Boost.Phoenix's syntax and compiler error messages, it has been noted that binding member functions within Boost.Phoenix can get ugly. As far as (b) is concerned, the community seems pretty far from reaching a consensus on whether a library described by (b) belongs in Boost. There are certainly libraries currently in Boost that could be pegged to satisfy (b) as well, though they all have other mitigating features they make their situation different from Local in some way. As far as (c) is concerned, several have acknowledged that a macro-based interface is necessary to implement local functions in C++03, and it seems to have been generally agreed that, given this limitation, Lorenzo has done an admireable job making the interface as easy-to-use as possible. Some find it ugly, others find it reasonable. In addition to the counterarguments of (a-c) above, the following facts weighed into my final decision: * Lorenzo has been engaging and in constant communication with the developer's list during the development of Local. This gives me confidence that he will continue to actively maintain (and improve?) Local. * The documentation is unanimously agreed to be of Boost quality. * The transition of some organizations from C++03 to C++11 may take several more years, and Boost has a history of supporting "ancient" compilers (for better or worse). The point being, a library that eases the transition from C++03 to C++11 has some merit based on current precedent. * There had been previous work on local functions by Alexander Nasanov and Steven Watanabe shared on the developer's list, suggesting a desire for this functionality for some time. * Local is approximately an extension of Boost.ScopeExit; indeed, it basically fulfills the request to Alexander Nasanov from the review result [2] of Boost.ScopeExit to create such an extension. Lastly, my own opinion of "what Boost is" factored in here. I view Boost as *partly* a collection of general purpose libraries that can be used in wide variety of applications (and thus Boost frequently acts as a staging ground for standard adoption). Based on review feedback, I believe Local satisfies this criterion; and based on the mailing list discussion, I believe this view of Boost is not entirely inconsistent with others on the mailing list. Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as it was the above general considerations. Regardless, I think independent of how the votes were counted, the "yes" votes outnumbered the "no" votes. This required some discretion on my part as not everyone who expressed an opinion submitted a formal review, and some participants were only arguing in favor of some specific point supporting either acceptance or rejection of Local. "Yes" reviews (7) -------- Krzysztof Czainski Andrzej Krzemienski Pierre Morcello Nat Lindon John Bytheway Edward Diener Gregory Crosswhite "No" reviews (3) -------- Vicente J. Botet Thomas Heller Hartmut Kaiser Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both submitted reviews but did not express an opinion (as far as I could tell) on whether Local should be included in Boost, though if I had to peg Paul's, it would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local in Boost (the aforementioned did not submit a formal review, though a formal review might be unnecessary if your vote is "no"). On the other hand, Brian Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael Fourquet, Matthias Schabel, and Robert Stewart participated in the discussion and argued in favor of some point that supported accepting Local in Boost. I want to be clear here that certainly not everyone in the aforementioned list even implied that they supported acceptance of Local (I would guess that only roughly half implied as much), but they indirectly helped its case by addressing arguments against inclusion. Overall, that indicates to me that more individuals support acceptance of Local into Boost than rejection. [Apologies for any name misspellings and absent accents.] Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating Boost.ScopeExit; 3 reviews felt there was nothing wrong with both Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the possibility of improving Boost.ScopeExit with the features provided by Local's exits. As such I'm inclined to let Alexander (who opposed any kind of merging of Local and Boost.ScopeExit) work with Lorenzo on improving Boost.ScopeExit as he sees fit, and hopefully both libraries can address this apparent duplication of functionality within their respective documentation to avoid user confusion. Regarding local::function::overload: Based on the review comments, it makes the most sense to add this to Boost.Functional. Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the other hand, there doesn't appear to be a compelling use case for BOOST_IDENTITY_VALUE. The following are some suggested *possible* improvements that reviewers brought up. This list is by no means exhaustive. Further, I personally don't think all of these suggestions are necessarily "good", but I think it's fair for Lorenzo (and the community) to consider them nonetheless. Parenthetic comments are my own opinions. * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases appear fairly narrow so it might be best to simplify the library and remove this capability.) * Use "this_" (as opposed to "_this") as an alias for "this" within function bodies, and possibly also within bind declarations. * Present Boost.PP sequence interface as a workaround for the variadic interface? (I don't have a problem with supporting both interfaces at the top level.) * "Local" and "Locale" look too much alike, suggesting a name change to "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? * Allow use without dependence on Boost.TypeOf. * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? (I don't mind the current macros.) * Explicitly separate bound variables from function parameters. (I think this suggestion has merit but I don't know what the interface could look like.) * Remove support for default parameters to simplify interface and documentation? (It doesn't seem like default function parameters would be very useful.) * Use "capture" instead of "bind" for the bind/capture keyword? (I like and prefer "bind".) Finally, here the links to the submitted formal reviews, for reference. Of particular note are Krzysztof's and John's reviews for their comments on the documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has already agreed to address the relevant conditions. Krzysztof Czainski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 Vicente J. Botet http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 Andrzej Krzemienski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 Paul A. Bristow [...cannot find link to review...] Pierre Morcello http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 Nat Lindon http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 Thomas Heller http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 Hartmut Kaiser http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 John Bytheway http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 Alexander Nasanov http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 Edward Diener http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 Gregory Crosswhite http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Finally, really big thanks to everyone for participating in the review and ancillary discussions. I attempted to be as transparent as possible in outlining the rationale for my decision above, but if you have any further questions, do not hesitate to ask. - Jeff, Review Manager for Local [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 [2] http://lists.boost.org/boost-announce/2008/05/0190.php

2 1

Calls to asio::io_service::run on io_service object in stopped state don't generate an error.
by Rory Hart 12 Dec '11

12 Dec '11

Hey I spent a day trying to work out why calls to io_service::run was returning directly without running my async operations. It was my own fault of course, the io_service was in a stopped state as I had previously called io_service::stop and needed to call io_service::reset on it. This is documented in both the stop and reset documentation if I had RTFM instead of just skimming the interface. Is there a reason io_service::run does not set an appropriate error on the passed boost::system::error_code object when this is encountered? Certainly it seems like an error case and would help circuital circumstances such as my own. If there is no obvious reason not to I will put in a feature request and attempt a patch (I haven't touched the boost code base before). Thanks -- Rory Hart http://www.roryhart.net http://www.relishment.com

1 0

incompatible serialization format of boost::property_tree between 1.44 and 1.48
by kpzhang 12 Dec '11

12 Dec '11

Hi, Several days ago I upgrade boost from 1.44 to 1.48 and I found that serialization format is not compatible for node of 'char' type. The serialization format of a "char a=0" node in boost1.44 is: { "a": "\0" } while in boost1.48 is: { "a": "\u0000" } For the format of boost1.44, read_json of boost1.48 will throw exception which complains unexpected escaped slash. Is this intended behavior or a bug or my misuse? Any suggestions is welcomed. Regards, Ivan

2 1

boost asio: Crash on timer.expires_from_now only with specific MSVC settings (whole program optimization)
by Florian Burkart 12 Dec '11

12 Dec '11

Hi, I am currently struggling with a crash that I find very hard to isolate. Please see attached three classes I am using (the one not included is FlamTimeMillis, but that is basically just my own time class). In any case, LiveTimer works absolutely fine in my unit tests. It works absolutely fine in both debug and regular release versions. However, when compiled under msvc with compile options /Ox /Oi /Ot /GL and linked with /LTCG (e.g. whole program optimization), it crashes. But only in my main program, and not in any test I try to create. But in the main program, it consistently crashes. According to the logs, it crashes between 3 and 4, e.g. the log looks like this: IN: : LiveTimer: RegisterTimedCallback 2011-12-12 07:02:00.000000: Locked mutex. IN: : LiveTimer: Expires from now -22405.5 A: 2011-12-12 07:02:00.000000 B: 2011-12-12 13:15:25.489000 C: -2.24055e+007 IN: : 1 IN: : 2 IN: : 3 This happens on the very first call to RegisterTimedCallback. Judging from it, it looks like it crashes on timer.expires_from_now(boost::posix_time::seconds((long)secondsToElapse)). I checked that I am in the correct LiveTimer, and that LiveTimer still exists. I tried loading the dump file into WinDbg, and I get the following output: XCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 77b68da9 (ntdll!RtlpWaitOnCriticalSection+0x000000bd) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 00000114 Attempt to write to address 00000114 PROCESS_NAME: Test.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000001 EXCEPTION_PARAMETER2: 00000114 WRITE_ADDRESS: 00000114 FOLLOWUP_IP: Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+4c [c:\program files (x86)\boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp @ 117] 0139784c b001 mov al,1 MOD_LIST: <ANALYSIS/> NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 FAULTING_THREAD: 000029b8 BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE LAST_CONTROL_TRANSFER: from 77b68cb8 to 77b68da9 STACK_TEXT: 0032ec44 77b68cb8 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0xbd 0032ec6c 0139784c 00953408 654f7f27 0032ecf0 ntdll!RtlEnterCriticalSection+0x150 0032ecac 0139e79a 0095015c 0032f93c ffffffff Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+0x4c [c:\program files (x86)\boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp @ 117] 0032ecdc 013d9d20 0095015c 0032ed38 00000000 Test!boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::expires_from_now+0x6a [c:\program files (x86)\boost_1_47_0\boost\asio\detail\deadline_timer_service.hpp @ 159] 0032ecfc 013d948f 0032ed28 654f7e57 0095716c Test!boost::asio::basic_deadline_timer<boost::posix_time::ptime,boost::asio::time_traits<boost::posix_time::ptime>,boost::asio::deadline_timer_service<boost::posix_time::ptime,boost::asio::time_traits<boost::posix_time::ptime> > >::expires_from_now+0x30 [c:\program files (x86)\boost_1_47_0\boost\asio\basic_deadline_timer.hpp @ 411] 0032ede0 013b1840 0032f900 00950188 0094f970 Test!Flam::Live::LiveTimer::EnqueueTimedCallback+0x33f [c:\users\florian\documents\liveenvv1\trunk\flamlib\live\livetimer.cpp @ 55] STACK_COMMAND: ~0s; .ecxr ; kb FAULTING_SOURCE_CODE: 113: // If the service has been shut down we silently ignore the cancellation. 114: if (::InterlockedExchangeAdd(&shutdown_, 0) != 0) 115: return 0; 116: > 117: mutex::scoped_lock lock(dispatch_mutex_); 118: op_queue<win_iocp_operation> ops; 119: std::size_t n = queue.cancel_timer(timer, ops, max_cancelled); 120: post_deferred_completions(ops); 121: return n; 122: } SYMBOL_STACK_INDEX: 2 SYMBOL_NAME: Test!boost::asio::detail::win_iocp_io_service::cancel_timer<boost::asio::time_traits<boost::posix_time::ptime> >+4c The source quoted is from \boost_1_47_0\boost\asio\detail\impl\win_iocp_io_service.hpp. Despite the fact that I can't isolate the error, everything I look at points to a problem somewhere within boost asio, or me not using asio correctly. Anyone any suggestions as to where to go from here? Would be much appreciated. What looks a bit suspicious to me (but that might be entirely wrong), is the line "// If the service has been shut down we silently ignore the cancellation.," because the error happens after the return statement linked to that comment was apparently not executed, and the service has actually been shut down. P.S. I know that I don't need to manage the queue myself and could just let asio handle it, however, eventually I would like to manage the queue more (e.g. edit some timers, cancel others, so I'd prefer to stick to a single timer and manage the queue myself).

1 0

is_dereferenceable.hpp fails to compile with Apple Clang 3.0
by István Csanády 12 Dec '11

12 Dec '11

Hi All, I am trying to use boost::iostreams. When I include boost/iostreams/filtering_streambuf.hpp (even if I don't declare any filtering_streambuf variables) I get the following compilation error: is_dereferencable.hpp: Parse Issue: Expected unqualified-id The problem is in this code: template <class T> struct impl { static typename boost::remove_cv<T>::type& x; BOOST_STATIC_CONSTANT( bool , value = sizeof(is_dereferenceable_::check BOOST_PREVENT_MACRO_SUBSTITUTION(BOOST_comma(*x,0))) == 1 ); }; Compiler: Apple Clang 3.0, with -std=c++0x flag Any help would be greatly appreciated. Thanks Istvan

4 4