October 2007 - Boost - lists.boost.org

Looking for Thread Pool Library
by Dean Michael Berris 06 Nov '07

06 Nov '07

Hi Everyone, Has there been any development with regards to a working, portable Boost.Thread based Thread Pool library? Personally I've been using the following sample idiom for achieving what a thread pool is supposed to be accomplishing -- and I'm wondering (aloud) whether there are any existing implementations out there that rely solely on Boost.Thread. Currently, the following code snippet requires Boost.Asio, but I'm not sure if there's something that may be distilled from the recurring pattern below: { using namespace boost::asio; using namespace boost; io_service process_queue; shared_ptr<io_service::work> sentinel(new io_service::work(process_queue)); thread_group processor_threads; for(unsigned int spawn_counter = THREAD_COUNT; spawn_counter > 0; --spawn_counter) processor_threads.create_thread( bind(&io_service::work, &process_queue) ); // add all void nullary functors and post them here process_queue.post(function_object); // once all the work has been queued, remove the sentinel sentinel.reset(); processor_threads.join_all(); } Will something like this be useful as a utility library? Insights, pointers, and suggestions would be very much appreciated. Have a great day everyone! -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis(a)gmail.com] [+63 928 7291459] [+1 408 4049523]

4 7

Boost.TypeErasure
by Steven Watanabe 06 Nov '07

06 Nov '07

AMDG After 6+ months I've finally gotten back to this. I'd like to get some feedback on my ideas before I continue. The current version is in the vault. The basic interface is derived from Alexander Nasonov's dynamic_any struct increment : concept_<increment, void(_&)> { template<class T> static void execute(T& t) { ++t; } } any<increment> x(1); increment()(x); assert(type_erasure::any_cast<int>(x) == 1); Note that unlike Boost.Function references will not work. int i; any<increment> x(boost::ref(i)); // NO!! The reason is that if references were allowed it would be to easy to kill yourself. (I've been there. I allowed references at first and then implemented operator+ in terms of operator+=. When the left argument is a reference this means that I made a shallow copy of the reference, called operator += on that, thus violating the expectation that operator+ does not modify its arguments) A function can also return another polymorphic object whose dynamic type is different. template<class R, class P2> struct at : concept<at<R, P2>, R(const P2&, int)> { template<class T> static typename T::value_type execute(const T& t, int i) { return(t[i]); } }; any<at<_1, _> > any_container(std::vector<int>(1, 2)); any<> value(at<_1, _>()(any_container, 0)); assert(type_erasure::any_cast<int>(value) == 2); In this example _ is the placeholder that refers to the current object. The placeholder _1 is used to refer to the return type of at. Since there is a mechanism for handling multiple objects, we can capture multiple objects simultaneously using a tuple: template<class P1, class P2> struct add : concept_<add<P1, P2>, P1(const P1&, const P2&)> { template<class T1, class T2> static T1 execute(const T1& t1, const T2& t2) { return(t1 + t2); } }; int array[] = {...}; type_erasure::tuple<_1, _2, where_<add<_1, _2> > > tuple(&array[0], 0); any<> pointer_to_second_element(add<_1, _2>()(type_erasure::get<0>(tuple), type_erasure::get<1>(tuple)); assert(type_erasure::any_cast<int*>(pointer_to_second_element) == array + 1); The first two arguments to tuple<...> specify which placeholders correspond to those elements. The element 0 will be match _1 and element 1 will match _2. Note that add is not a true multimethod. It's arguments must ultimately come from the same place. i.e. you can apply it as many times as you want since its return type is known to always be the same as its first argument, but you cannot mix another type in e.g. long instead of int. Another thing to note is that it is always okay to discard functions. In the last example the result of calling add itself supports add since it is the same type. I don't care about that so I construct an any<> from it. I haven't shown it here, but any<...> takes up to 10 parameters or an MPL sequence. I can assign one any<> to another which has an arbitrary subset of its functions. One that has both increment and decrement can be assigned to one that supports only increment or to one that supports only decrement. Future Work: I intend to enable boost::ref iff there are no mutating operations for the type. There should be a class for references, so that you can throw away some operations without making a copy. I can implement multimethods if (a) The return type is fixed at compile time and (b) Every type specifies (through a traits template) a list of possible overloads involving it. Functions should be able to handle cases such as template<class P1, class P2> struct some_function : concept_<some_function<P1, P2>, void(const P1&, const P2&)> { //... }; any<some_function<_, std::string> > a1; tuple<_1, _2, where_<some_function<_1, _2> > > t(a1, std::string("The quick brown fox jumps over the lazy dog.")); where some of the arguments are any<>s and others are are of known type. In Christ, Steven Watanabe

4 6

The big web site push.
by Rene Rivera 05 Nov '07

05 Nov '07

As part of the 1.35.0 release I'm in charge of getting the new web site in shape. The idea is to move to the new independent web site content to ease the release management to only worrying about the libraries themselves. And along the way we also get the new look & feel :-) But since I'm not superman I need help in moving the existing content over to the new structure. Since we are now living in the new Trac age, I created a milestone and tasks for all the content I could immediately find that needs to move <http://svn.boost.org/trac/boost/milestone/Website%201.0>. So if you want to help... Jump right in. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 4

[1.35] Unmerged changes from 1.34.1
by David Abrahams 05 Nov '07

05 Nov '07

I recently started looking at what changes in my libraries may not have made it into the trunk from 1.34.1. The easiest way was to go to my boost-trunk working copy and svn merge https://svn.boost.org/svn/boost/tags/merged_to_1_34_0/boost https://svn.boost.org/svn/boost/tags/Version_1_34_1/boost What I saw in libraries that weren't my own gave me pause for concern. There are a large number of files with a 'C' or an 'M' next to them. Neither is *necessarily* an indication of a problem, but 'M' (meaning "merged") especially is *likely* to indicate unmerged changes, and 'C' (meaning "conflict") may also indicate unmerged changes. I went and inspected a few of those files and the ones I looked at all seemed suspicious to me. I strongly suggest that all other Boost authors do the command above and inspect "merged (M)," "conflict (C)," and "added (A)" files that they may have touched during the 1.34.x release cycle, or we may find that we've dropped important improvements. One place you should especially check is in your test/ directories, to make sure that you haven't unintentionally dropped any tests between then and now. If your testing is complete and you make sure nothing is dropped, in theory, dropped features and bugfixes won't be able to hide. But there are also documentation changes, so I wouldn't take anything for granted ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

8 17

[Spirit] Using real_parser with user-defined numeric types
by John Maddock 05 Nov '07

05 Nov '07

I'm having a problem using real_parser, I define the parser as: real_parser<some-type> const rr_p; Then use it as: str_p("range")[assign_a(started, false)] && rr_p[assign_a(a)] && rr_p[assign_a(b)] Followed by a list of other alternative commands. When some-type is float/double/long double it all works OK, but as soon as I change some-type to boost::math::ntl::RR then I have two problems: 1) The code doesn't compile: spirit looks for std::pow rather than relying on ADL to find the right overload, I can work around this one for now by importing boost::math::ntl::pow into namespace std. 2) The parser doesn't work, any simple command like "range 0 1" is rejected as invalid. Is there something else I need to do here to enable support for UDT's? Thanks, John.

3 7

Problem with error_code.hpp dependency on winerror.h
by Emil Dotchevski 05 Nov '07

05 Nov '07

I am wondering why does error_code.hpp include <winerror.h>? All it does is translate the error codes defined in <winerror.h> to a enum values defined in error_code.hpp; however this enum is windows-specific anyway and the user can't use it without <winerror.h>. So, why not leave it up to the user to include <winerror.h> if they care about those values to begin with? My problem is that I get a compile error under Windows, because I (indirectly) include error_code.hpp in my own cpp that is supposed to be platform-independent, and as such it does not see the platform SDK. Emil Dotchevski

4 9

Mutli index container - performance varation when erasing large amount of rows in different computers
by Avi Revivo 05 Nov '07

05 Nov '07

Hi All, I am trying to use boost Multi Index Container in my company product to replace an old container that gave the same functionallity but with bad performance. The mutli index container contains 2 non unique ordered indices. The mutli index container will be used to insert large amount of rows sequentially and an erase using one of the ordered indices that will evantually erase around 10,000 rows in one erase operation since the container will contain many duplicate values of the delete key. Testing the insertion of 10,000 rows takes around 60-80ms on a standard PC 3.2GHZ. On a HP G4 server (2 xeon 3.2 cpu's, 4Giga of memroy) the performance is a little better. In both cases the insertion is consistent. However, while erasing elements using one of the indices which incur the erase of 10,000 elements takes around 30ms on the standard PC. However, on the HP G4 the deletion is inconsistent and far worse. It takes between 200ms to 1.4 seconds on different deletion cycles. I am using the same products exactly on both machines. The HP G4 does not have a development envoirment installed on it, the standard pc have visual studio 2005 installed on it. Does anyone have any idea what may cause such exterme difference? Thanks in advance, Avi Nice Systems ltd. -- View this message in context: http://www.nabble.com/Mutli-index-container---performance-varation-when-era… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Deterimining interest in: Optional Polymorphic Value object with Small Object optimization
by Corrado Zoccolo 04 Nov '07

04 Nov '07

Hi Following the recent interest in clone pointers and Polymorphic value object wrappers, I developed a slightly feature enriched Polymorphic Value object, that implements the small object optimization, and models the Optional Pointee concept. It follows a non-intrusive approach to cloning. The code can be found in the boost vault: *http://tinyurl.com/3a6sq8* Motivation: Dynamic polymorphism is a valuable but underestimated tool to the modern C++ programmer. It for example allows the implementation of type erasure and other techniques for physical decoupling. It is also unavoidable every time dynamic dispatching is needed. Unfortunately solutions based on it may often be slow, because traditional dynamic polymorphism is always paired with dynamic allocation. The proposed tool is targeted to ease the usage of dynamic polymorphism in modern C++ context, by giving value semantics to polymorphic objects, as well as providing a well known optimization technique to avoid dynamic allocation when the involved objects are small. Dynamic polymorphism, value semantics and small object optimization constitute a powerful receipt to solve such problems. As evidence boost::function, among the most valuable tools for type erasure and physical decoupling available in boost, is using all three of them. This tool is meant to be a low level tool, on which powerful abstractions like boost::function could be built easily. Basic Usage Example: #include "optional_poly.hpp" #include <iostream> // class with one virtual method but not virtual destructor // optional_poly will know the derived type, so it will call the correct destructor nevertheless struct B { virtual operator int() {return 0;}}; // lack of virtual destructor is intentional // Derived class, with side effect in destructor to show functionality, and overloaded virtual method to determine which one was called struct D : B { operator int() {return 1;} ~D() { std::cerr<<"Got it\n"; } void swap(D&) {} private: void operator=(D const &); }; // swap reachable via ADL. optional_poly will prefer (by default) this to implement its swap method. Using a trait, you can specify if a swap method or no swap at all should be used for a given type void swap(D& a,D& b) { a.swap(b); } int main() { // optional_poly constructor and operator= require that the static type match the dynamic one. // The following commented code is invalid, and will assert at runtime // const B& d=D(); // boost::optional_poly<B> z=d; // asserts, because optional_poly should be constructed with the concrete derived type // this is the correct way to initialize optional_poly. D must be derived from B (static assertion otherwise). boost::optional_poly<B> z=D(); std::cerr<<*z<<"\n"; // this prints 1 boost::optional_poly<B> s; // uninitialized (empty) optional_poly for interface B s.swap(z); // now s has a D, while z is empty std::cerr<<*s<<"\n"; // prints 1 return 0; } A bit more complex example: #include "optional_poly.hpp" #include <boost/none.hpp> #include <iostream> // we will show how simple callable objects can be returned easily and efficiently from a function (i.e. we implement a really small subset of boost::function) struct Callable { virtual void operator()() const=0; }; // inheritance is used here. This wrapper can host function pointers or functors seamlessly, exposing to the outside the Callable interface template<class T> struct MakeCallable: Callable { MakeCallable(const T& t) : val(t) {} T val; void operator()() const { val(); } }; void my_fun() { std::cout<<"got 1\n"; } struct MyFunc { void operator()() const { std::cout<<"got 2\n"; } }; // the function returning different Callable objects depending on the value of the parameter boost::optional_poly<Callable> foo(int i) { switch(i) { case 1: return MakeCallable<void (*)()>(my_fun); case 2: return MakeCallable<MyFunc>(MyFunc()); } return boost::none; } // main shows how foo() is invoked, and its result is used int main() { boost::optional_poly<Callable> c; for(int i=0;i<3; ++i) { c=foo(i); if(c) { std::cout<<"Going to call c for "<<i<<" ... ";(*c)(); } else { std::cout<<"empty c for "<<i<<"\n"; } } return 0; } Output: empty c for 0 Going to call c for 1 ... got 1 Going to call c for 2 ... got 2 Wasn't this easy? And this small example did not dynamically allocate any memory, because the Callable objects are all smaller than the small object threshold (default value is 128, can be overridden specifying a second template parameter to optional_poly, e.g. optional_poly<Callable,0> will always allocate from the heap). Sounds interesting for being submitted to boost? Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto: zoccolo(a)di.unipi.it PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

14 42

Comments about N2320
by Yuval Ronen 03 Nov '07

03 Nov '07

Hi, After reading most of N2320, I have a few comments: * thread::id has operator== and operator!= declared twice. Once in namespace scope, and a second time inside class thread. Second time is with operator< and his friends. * Thread cancellation is new, and disable_cancellation/restore_cancellation are even newer. They are new for C++ programmers, and maybe new for *all* programmers (I never heard of a language with them). I'm not sure if it's a good idea to standardize them before we get some real-life experience with thread cancellation. * Time issues. To my eyes, it looks not pretty trying to get threading with time issues standardized before we have std::date_time. Making it a templated type not because we want genericity, but because we don't have the type we want yet, makes it look coerced. I think it's best to drop the time-related stuff, and add it properly together with date_time. Using the timed version of thread::join(), mutex::lock() and condition::wait() are very rare, and I think (hope) they can be implemented externally using native_handle(). * I see that you chose not go accept a mutex in condition's constructor. If that is so, why make the condition class templated, instead of only the wait() functions, as is in Boost.Thread? * If C++0x is going to have lambda support (is it?), then maybe the not-accepting-predicate overloads of condition::wait are no longer needed, and can be removed? I think the major reason why people use that overload is because they are too lazy to write a functor. With core support for lambda, it's a breeze. This will solve the other problem (mentioned in some other thread in this ML) about absolute vs. relative times. * Back then we had a discussion about unique_lock, which was never finished. I claim that there is no need for a state where mutex() != 0 && owns() == false, which means that defer_lock is not needed. There is one example in the document using defer_lock, which I think can be done in another way. That example goes like: Record& Record::operator=(const Record& r) { if (this != &r) { std::unique_lock<std::mutex> this_lock(mut, std::defer_lock); std::unique_lock<std::mutex> that_lock(r.mut, std::defer_lock); std::lock(this_lock, that_lock); // Both source and destination are locked // Safe to assign // ... } return *this; } If we change the first 3 lines of the 'if' to: std::lock(mut, r.mut); std::unique_lock<std::mutex> this_lock(mut, std::accept_ownership); std::unique_lock<std::mutex> that_lock(r.mut, std::accept_ownership); then it works without defer_lock. This allows us to: 1. Make unique_lock's interface simpler. 2. Make sizeof(unique_lock) smaller - no need for bool owns. 3. Make unique_lock more similar to unique_ptr, which makes it more intuitive. 4. Make std::lock simpler in the way that it doesn't need to accept locks, only mutexes. In general it seems you paid a lot of attention to being able to pass a lock instead of a mutex wherever possible. I think it's absolutely not necessary. It's an undue complication. * Other than that - very nice :) Yuval

15 48

[1.35.0] Developer preparation
by Beman Dawes 02 Nov '07

02 Nov '07

Until further notice, the plan is to do quarterly Boost releases, and stick to that schedule even if updates for particular libraries aren't ready. If a library on the trunk isn't ready for a release, the prior release will be used for that library. I hoping for a final cut-off date of Friday, October 19, for making "go/no-go" decisions on which library updates make it into 1.35.0. That means libraries with updates to be included should be passing regression tests on trunk well before then. The process of merging into the release branch will start sooner for libraries already ready. Here is what developers should be doing over the next two weeks: * Start watching the regression tests at http://beta.boost.org/development/tests/trunk/developer/summary.html * For release criteria compilers, fix or markup all failures caused by your library's code. Fix or markup failures caused by your library's code for other compilers according to your own judgment. * For release criteria compilers show failures you think are caused by some other library's code, or by test configuration problems, post list notifications directed at the library or tool causing the problem. For other compilers, do the same if you wish. * For testing on the trunk to be a reliable indicator of release stability, prerequisite libraries on the trunk must be ready for release. If the trunk for your library isn't going to be ready in time for this release, please make a branch of the trunk with your library's name, and "merge" the trunk for your library so it is identical to 1.34.1. Note that if other libraries depend on your library, and you library is causing those libraries to break, you need to fix the trunk or return it to 1.34.1 within the next few days so that you don't impede the other libraries. Now the fun begins, --Beman

8 20