- Boost - lists.boost.org

problems with recursive_timed_mutex and scoped lock wont compile in version 1.39
by Clark Sims 07 Sep '09

07 Sep '09

I can compile the following code fine in boost 1.33.1 but it generates compiler errors in version 1.39. I am using visual studio 2005. I will post the code, and then post the compiler errors: #include <iostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/thread/recursive_mutex.hpp> using namespace std; //using namespace boost; using boost::mutex; using boost::thread; using boost::recursive_timed_mutex; using boost::xtime; boost::recursive_timed_mutex hello_mutex; void hello( int thread_id, int iter) { cerr << thread_id << " : " << iter << endl; } void rand_xtime( xtime* xt) { xtime_get( xt, boost::TIME_UTC); //xt.nsec += (rand() % 1000000000); xt->sec += 1 + rand()%5; } void say_hello( int thread_id) { for (int iter=0; iter<5; iter++) { xtime xt; rand_xtime( &xt); thread::sleep(xt); rand_xtime( &xt); { recursive_timed_mutex &refer_hello = hello_mutex; const xtime& refer_xt = xt; recursive_timed_mutex::scoped_timed_lock lock1( refer_hello, refer_xt); if (lock1) { hello( thread_id, iter); } } } } void hello1() { say_hello( 1); } void hello2() { say_hello( 2); } int main() { boost::thread thrd1(hello1); boost::thread thrd2(hello2); thrd1.join(); thrd2.join(); return 0; } Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Warning: cannot find Makefile.TimedMutex.dep cl.exe /nologo /Ob0 /W3 /EHs /MD /GR /I ".." /D NDEBUG /D WIN32 /D _CONSOLE /FD /c /Fo"Release\TimedMutex\I386\TimedMutex.obj" "TimedMutex.cpp" TimedMutex.cpp c:\boost_1_39\boost\thread\win32\basic_recursive_mutex.hpp(64) : error C2679: binary '+' : no operator found which takes a right-hand operand of type 'const boost::xtime' (or there is no acceptable conversion) c:\boost_1_39\boost/date_time/posix_time/date_duration_operators.hpp(31): could be 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::months &)' [found using argument-dependent lookup] c:\boost_1_39\boost/date_time/date_duration_types.hpp(132): or 'boost::gregorian::date boost::date_time::months_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::months_duration<base_config> &)' [found using argument-dependent lookup] with [ base_config=boost::gregorian::greg_durations_config ] c:\boost_1_39\boost/date_time/posix_time/date_duration_operators.hpp(75): or 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::years &)' [found using argument-dependent lookup] c:\boost_1_39\boost/date_time/date_duration_types.hpp(244): or 'boost::gregorian::date boost::date_time::years_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::years_duration<base_config> &)' [found using argument-dependent lookup] with [ base_config=boost::gregorian::greg_durations_config ] c:\boost_1_39\boost/date_time/time.hpp(139): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::gregorian::date_duration &) const' with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ] c:\boost_1_39\boost/date_time/time.hpp(159): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::posix_time::time_duration &) const' with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ] while trying to match the argument list '(boost::system_time, const boost::xtime)' c:\boost_1_39\boost/thread/locks.hpp(364) : see reference to function template instantiation 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::timed_lock<boost::xtime>(const Duration &)' being compiled with [ underlying_mutex_type=boost::detail::basic_timed_mutex, Duration=boost::xtime ] c:\boost_1_39\boost/thread/locks.hpp(363) : while compiling class template member function 'bool boost::unique_lock<Mutex>::timed_lock(const boost::xtime &)' with [ Mutex=boost::recursive_timed_mutex ] TimedMutex.cpp(36) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled with [ Mutex=boost::recursive_timed_mutex ] NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 8\VC\BIN\cl.exe"' : return code '0x2' Stop.

1 0

Testing down
by K. Noel Belcourt 07 Sep '09

07 Sep '09

Hi, I'm sorry to report that over the weekend the machine and file systems running Boost testing failed. I'm working on resurrecting the testing on another system but it may be tomorrow before testing comes back online. I apologize for the disruption. -- Noel Belcourt

1 0

[Graph] 1.40 Static Link Issue
by Gordon Smith 07 Sep '09

07 Sep '09

There seems to be an unused bool in fruchterman_reingold.hpp: bool vertex_migration = false; Which will cause link errors if included in more than one statically linked library. Gordon.

1 0

[mpi] non-char strings
by Isidor Zeuner 07 Sep '09

07 Sep '09

The last two checkouts I installed both failed passing strings through boost::mpi communication methods when the element type was not char. So maybe someone besides me will have use for the attached patch which makes it work again. I assume this way of passing strings isn't here to stay anyway since boost::serialization also handles strings. Best regards, Isidor

3 5

Release branch test results with MPI dropped on floor
by Steve M. Robbins 06 Sep '09

06 Sep '09

Hi, Now that 1.40 is out, can we get the release branch testing result scripts fixed so that they understand MPI runs? c.f. http://lists.boost.org/Archives/boost/2009/08/155466.php http://lists.boost.org/boost-testing/2009/08/6353.php Thanks, -Steve

4 4

[hs] Quickbook highlighting doesn't work in KDE 4.3
by Andrey Semashev 06 Sep '09

06 Sep '09

I'm not sure it's the right place for this, so sorry if it's off-topic. I'm trying to use Boost.HS* with Kate from KDE 4.3 on Ubuntu 9.04 but it doesn't work. There appears no "boost::hs" group in the Toost->Highlighting menu, neither does it color the quickbook files. Have anyone run into such kind of problems? PS: I successfully used Boost.HS with previous KDE versions (4.1 for sure, not sure about 4.2). This tool really helps to document the library, many thanks to the author. * http://www.drivehq.com/web/matias.capeletto/boost_hs/doc/html/index.html

2 2

Failures for GCC 4.4.1 with gnu++0x
by Beman Dawes 06 Sep '09

06 Sep '09

9 19

[Boost.Function] How about parallel functions?
by Kasra 06 Sep '09

06 Sep '09

Hi, I required to call few functions is separate threads and use the results. However, the code for this looks really ugly, you have to create threads, then join the threads when ever you require the result of the functions. So I have created a boost.parallel_function library that does this seamlessly just like invoking a normal function and it only joins the thread when the value of the function result type is required. Is this library of any interest to any one? Here is the a hello world example: #include <cstdlib> #include <limits> #include <boost/parallel_function.hpp> using namespace boost; int F0() { volatile int x = 0; for(int i=0; i<std::numeric_limits<int>::max()/1024; i++) x ^= std::rand(); return (int)x; } int F2(int y) { volatile int x = 0; for(int i=0; i<std::numeric_limits<int>::max()/512; i++) x ^= std::rand(); return (int)x ^ y; } int main() { typedef boost::parallel_function< void ( ) > f0_type; typedef boost::parallel_function< void (int) > f1_type; f0_type f0( &::F0 ); f1_type f1( &::F1 ); f0_type::result_type r0 = f0(); f1_type::result_type r1 = f1(32); // use r0 and r1 as if they are int r0 += 34; int value = r1 *= r0 + 452; std::cout << "Hello world " << value << std::endl; return 0; } With Best Regards Mr. Kasra Nassiri Department of Mathematics & Computer Science Imperial College London

3 2

Bug in date_time::subsecond_duration
by Jon Spencer 06 Sep '09

06 Sep '09

There is a needless loss of range in the constructor of date_time::subsecond_duration. The argument is multiplied by the resolution of the base_duration, which could potentially overflow, and then divided by frac_of_second. The patch below reduces the amount of overflow and is identical if one resolution is an integer multiple of the other. The same technique is used elsewhere in the file. Also see this posting on the subject (http://lists.boost.org/boost-users/2008/10/41763.php) --- boost/date_time/time_duration.hpp +++ boost/date_time/time_duration.hpp @@ -267,7 +267,7 @@ public: typedef typename base_duration::traits_type traits_type; explicit subsecond_duration(boost::int64_t ss) : - base_duration(0,0,0,ss*traits_type::res_adjust()/frac_of_second) + base_duration(0,0,0,traits_type::res_adjust()<frac_of_second?ss/(frac_of_second/traits_type::res_adjust()):ss*(traits_type::res_adjust()/frac_of_second)) {} };

1 0

Weak pointer to object not managed by a shared_ptr
by Mateusz Loskot 05 Sep '09

05 Sep '09

Hi, One of the smart pointer techniques [1] explains use of weak_ptr pointer to object not managed by a shared_ptr. [1] http://www.boost.org/doc/libs/1_40_0/libs/smart_ptr/sp_techniques.html I'm wondering what would be practical use case of that? Is it a part of any of known idioms or patterns? Also, is it valid to assume that this technique can extend lifetime of X so of the internal integral X::i_ ? Here is a simple test case based on the technique explained in the smartptr docs [1] with my questions marked using XXX tag: /// begin of program /////////////////////////////////////////////// #include <exception> #include <iostream> #include <boost/shared_ptr.hpp> #include <boost/weak_ptr.hpp> using namespace std; using namespace boost; struct null_deleter { void operator()(void const *) const { std::cout << "deleter\n"; } }; class X { public: explicit X(int i): this_(this, null_deleter()), i_(i) {} X(X const & rhs): this_(this, null_deleter()), i_(rhs.i_) {} X & operator=(X const & rhs) { i_ = rhs.i_; return *this; } weak_ptr<X> get_weak_ptr() const { return this_; } int get_i() const { return i_; } private: shared_ptr<X> this_; int i_; }; int main() { try { shared_ptr<X> spx; { X x1(7); // XXX: lifetime is extended here? spx = shared_ptr<X>(x1.get_weak_ptr()); } // XXX: No exception. x1 is still alive, so the pointer valid? cout << spx->get_i() << std::endl; } catch (bad_weak_ptr const& e) { cerr << e.what() << endl; } catch (exception const& e) { cerr << e.what() << endl; } catch (...) { cerr << "unknown error\n"; } return 0; } /// end of program /////////////////////////////////////////////// No exception is thrown and I can It seem that the lifetime of x1, automatic object, has been extended beyond its "natural" scope. Am I correct? However, if I replace retrival of shared_ptr with weak_ptr then of course bad_weak_ptr exception is thrown: shared_ptr<X> spx; weak_ptr<X> wpx; { X x1(7); wpx = x1.get_weak_ptr(); } spx = shared_ptr<X>(wpx); cout << spx->get_i() << std::endl; I'm having problems with understanding of what causes the extention of lifetime of X (so of internal X::i_ object). Is this mechanism similar to binding r-value to "const reference"? I would appreciate if anyone could help me to understand it. References to the C++ standard would be great too. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

7 9