December 2008 - Boost - lists.boost.org

[thread/interprocess] could we improve recursive_mutex constructor
by vicente.botet 24 Jan '09

24 Jan '09

Hi, the recursive_mutex constructor initialize/set/destroy the pthread_mutexattr_t every time. I'm wondering if we can improve the efficiency storing this on a static variable which will be initialized once. What could be the better way to initialize this static variable? Note: the same applies to interprocess mutexes. recursive_mutex() { // begin code that can be initialized only once pthread_mutexattr_t attr; int const init_attr_res=pthread_mutexattr_init(&attr); if(init_attr_res) { throw thread_resource_error(); } int const set_attr_res=pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE); if(set_attr_res) { throw thread_resource_error(); } // end code that can be initialized only once int const res=pthread_mutex_init(&m,&attr); if(res) { throw thread_resource_error(); } // begin code that can be removed BOOST_VERIFY(!pthread_mutexattr_destroy(&attr)); // end code that can be removed } Regards, Vicente

2 2

[thread] Why the at_thread_exit cleanup function be const?
by vicente.botet 24 Jan '09

24 Jan '09

In addition, if a remove the const on operator()() struct mycallable1 { void operator()() { std::cout << "mycallable1" << std::endl; }; }; void my_thread() { std::cout << "my_thread" << std::endl; mycallable1 x; boost::this_thread::at_thread_exit(x); } I get the following error: gcc.compile.c++ ..\..\..\bin.v2\libs\interthreads\test\hello_world.test\gcc-4.3.2\debug\target-os-cygwin\threadapi-pthread\threading-multi\hello_world.o ../../../boost/thread/detail/thread.hpp: In member function `void boost::detail::thread_exit_function<F>::operator()() const [with F = mycallable1]': ..\example\hello_world.cpp:52: instantiated from here ../../../boost/thread/detail/thread.hpp:474: error: passing `const mycallable1' as `this' argument of `void mycallable1::operator()()' discards qualifiers Why the cleanup function must be const? Best, Vicente ______________________ Vicente Juan Botet Escribá

2 2

manipulators for filtering_stream s
by Roland Schwarz 22 Jan '09

22 Jan '09

Surprisingly I was not able to find on the net code that would give me a smart way to indent a stream. So I wrote a little filter based on the boost iostreams library. My first attempt was: boost::iostreams::filtering_ostream out; indent_filter ind(4); out.push(ind); out.push(std::cout); However trying to control it via e.g. ind.in() ind.out() turns out to be problematic interface since, 1) out.push() takes a copy of ind 2) the interface ind.in() is suboptimal. With my attached example it is possible to: #include "indent.hpp" ... boost::iostreams::filtering_ostream out; indent_filter::push(out,2); out.push(std::cout); ... And use it like so: out << "Hello Filter!\n" << indent_in << "this is\n" << "indented\n" << indent_out << "until here\n" ; Which will result in output: Hello Filter! this is indented until here The state is stored in the ios base class of the stream, by way of the pword mechanism. Consequently the filter stream even may be downcast to a basic_ostream, and the indenter will still work. E.g. with out defined as above: ... foo(out); ... void foo(std::ostream& out) { out << indent_in << "out is a downcast filter_stream\n" << indent_out << "end of indentation\n" ; } If you want to try it out, you just need to include the header indent.hpp. If someone thinks the snippet is usable either as an example for the iostreams library or the filter streams manipulator idea is worth generalizing to make it usable for other filters too, I would be glad to hear from you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

5 17

[thread] proposal to manage portable and non portable thread attributes
by vicente.botet 22 Jan '09

22 Jan '09

Hello, Boost.thread has already a non portable interface to get the thread handle class thread { public: ... typedef np_native_handle_type native_handle_type; native_handle_type native_handle(); ... }; Boost.Thread do not allow to pass thread attributes on the thread constructor. I supose that this is due to portable issues. Could we identifiy which attributes are portable and which one not? The portable attributes (as stack size, ...) can be grouped on a thread_attributes class. In order to be able to pass whatever attribute to the thread constructor we can add the setting of non portable attributes to this thread_attributes class, and making the thread constructor take a thread_attributes in addition to the existing parameters. class thread { public: class thread_attributes { // portable attributes public: // set/get of attributes // .. #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) private: pthread_attr_t native_attributes; public: set_np_attributes(const pthread_attr_t* h); // ... other #else #error "Boost threads unavailable on this platform" #endif }; thread(const thread_attributes*p, F f,A1 a1); ... }; The portable application needing some specific configuration can construct portable threads using the following schema thread::thread_attributes attr; // set portable attributes // ... #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) // ... pthread version pthread_attr_t native_attributes; pthread_attr_init(&native_attributes); pthread_attr_setstacksize(&native_attributes, 1000000); attr.set_np_attributes(&native_attributes); #else #error "Boost threads unavailable on this platform" #endif thread th(attr, f,ctx); What do you think? Vicente

3 3

[random] A much faster Poisson variate generation
by Ross Levine 21 Jan '09

21 Jan '09

Hello, I have modified the poisson_distribution class to use an updated version of Ahrens and Dieter's PD algorithm for generating Poisson variates, as described in "Computer Generation of Poisson Deviates from Modified Normal Distributions." Is this allowed in Boost, and is there interest? The current algorithm is O(mean), while PD is bounded time. In addition, the current implementation fails for mean >> 750. PD does, however, use a lookup table and thus has a non-trivial constructor and needs 36 * sizeof(RealType) + 1 * sizeof(IntType) bytes per poisson_distribution object. Please let me know if this is desired. Ross

2 7

Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 19 Jan '09

19 Jan '09

Futures Join the review and discussion starting January 5, 2009. I need commitments for reviews from threading experts on the two Futures library candidates. Braddock Gaskill - http://braddock.com/~braddock/future Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp Early comments are welcome.

9 16

Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 15 Jan '09

15 Jan '09

>> Is the expected result of the review to choose a library (or none) or to >> create a third library that is a mixture of the two? I have no expectations about the results. I'm interested to hear your views and those of the authors about how to proceed.

3 2

Proposal: Add Loki Library's SafeFormat to Boost:
by Tom Browder 11 Jan '09

11 Jan '09

The last Loki thread I see here is the one from 2002 discussing adding Loki to Boost. I asked Andrei once about doing that specifically for the Loki SafeFormat functions (FPrint, Printf, and SPrintf) and he said FPrintf wasn't good enough yet. However, I find all of them very useful and would love to see them added to the Boost library I know Boost has Format now, but SafeFormat has some advantages over Boost.Format, one of which is that FPrintf can be output to C++ streams as well as to FILE pointers--very handy when one is gradually converting legacy code to using C++ streams. In addition, I find the SafeFormat family much easier to use than Boost.Format. Andrei's original comments regarding FPrintf's shortcomings are here: https://sourceforge.net/forum/message.php?msg_id=4525195 His "Dr. Dobb's Journal" article describing SafeFormat is here: http://www.ddj.com/cpp/184401987 Thank you for your consideration. Warmest regards, -Tom Tom Browder Niceville, Florida USA

21 96

[Range] make range_const/mutable_iterator<C>::type non-existent if C is non-range
by Arno Schödl 10 Jan '09

10 Jan '09

Hello, the attached patch makes boost::range_const/mutable_iterator<C>::type non-existent if C does not have the right typedef C::(const_)iterator. For me, this fixed a compilation error in the following situation: template<class Rng, class Val, class BinPred> typename boost::range_const_iterator<Rng>::type lower_bound(Rng const& rng,Val const& x,BinPred pred); // not taken template<class It, class Val, class BinPred> It lower_bound(It itBegin,It itEnd,Val const& x) { // taken return itBegin; // dummy } main() { std::vector<int> vecn; int n=6; lower_bound( vecn.begin(), vecn.end(), n ); } The return type of the overload that is not taken is range_const_iterator< std::vector<int>::iterator >::type. With the old range_const_iterator, this typedef exists, which makes the overload compile, but evaluates to std::vector<int>::iterator::const_iterator, which does not exist and causes a compiler error. With the patch, range_const_iterator< std::vector<int>::iterator >::type already does not exist, and the compiler aborts checking this overload. I don't see a way to fix this without changing or largely reimplementing range_const_iterator, because the mere presence of the "type" typedef in the default case of range_const_iterator causes the problem. Any chance to get this adopted? Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

3 8

[lambda] patch to make lambda recognize operator+ for std::string
by Steven Watanabe 08 Jan '09

08 Jan '09

AMDG The attached patch fixes https://svn.boost.org/trac/boost/ticket/781 Okay to commit? In Christ, Steven Watanabe

2 1