- Boost - lists.boost.org

[threads] API Design Question
by Alexander Bernauer 06 Feb '09

06 Feb '09

Hello Why is it, that the wait and timed_wait functions of the condition_variable class do not encapsulate the problem of spurious wakeups? I wonder whether there are good reasons. I have seen libraries which do so. Do they miss a corner case? For illustration here is a sketch of a wrapper class ---8<--- class save_condition_variable { public: save_condition_variable() : waiting(0), wakeup(0) { } void notify_one() { if (wakeup < waiting) { ++wakeup; } cond.notify_one(); } void notify_all() { wakeup = waiting; cond.notify_all(); } void wait(unique_lock<mutex>& lock) { ++waiting; do { cond.wait(lock) } while (wakeup==0); --waiting; --wakeup; } bool timed_wait(unique_lock<mutex>& lock, system_time const& abs_time) { ++waiting; bool res = true; while(wakeup==0 and res) { res = cond.timed_wait(lock, abs_time); } --waiting; if (res) --wakeup; return res; } private: condition_variable cond; int waiting; int wakeup; }; --->8--- Having the spurious wakeup problem handled by the library is a significant increase of comfort for both developers and maintainers. regards Alex

5 9

support for gcc hidden visibility in shared libraries
by Stjepan Rajko 06 Feb '09

06 Feb '09

Hello, Many (almost all?) linked boost libraries don't work as shared libraries when compiled with the -fvisibility=hidden switch on gcc version>=4. I am wondering whether there is interest in making them work under these circumstances, as it might not be too hard to do, and there seems to be some benefit to it. To my limited understanding, making a symbol visible in a shared library using, say, __attribute__ ((visibility("default"))) on gcc, is analogous to using __declspec(dllexport) on windows. Many boost libraries already use macros that apply __declspec(dllexport) on windows - so these macros could set to expand to __attribute__ ((visibility("default"))) on gcc. Even better, a boost-wide macro could be added to the config headers. More information on this can be found here: http://gcc.gnu.org/wiki/Visibility Just to note, I have very limited understanding of compiling/linking and I might not have a full grasp of everything involved here. Also, my only reason for thinking that -fvisibility=hidden should be supported is that for a long time now, I haven't been able to use boost shared libraries on my os x platform, and only now I realized that the reason for this is that I had stuck -fvisibility=hidden in my user-config.jam a long time ago to suppress some warnings. Nonetheless, it seems like there are benefits to supporting it that go beyond preventing people like me from accidentally shooting themselves in the foot. Kind regards, Stjepan

6 16

Boost Lambda Expressions Serialization
by Emad Soroush 06 Feb '09

06 Feb '09

Hello there, I am using boost lambda library to show some type of expressions. I am trying to send the lambda expression remotely. Is there anyway to serialized the boost lambda expression? I am aware of the Boost:Serialization library, but it doesn't seem be able to serialize expressions Thanks Emad

2 1

Coverity Static Code Analysis
by Michael Fawcett 05 Feb '09

05 Feb '09

Purely out of curiosity, how come Boost isn't at Rung 1 in the Coverity Scan Ladder? http://scan.coverity.com/ Boost and Boost.Build are both listed in Rung 0, so it appears that the only step left is selecting a Boost/Coverity liaison. http://scan.coverity.com/newproj.html --Michael Fawcett

14 25

[svn] sandbox access
by Kasra 05 Feb '09

05 Feb '09

Hi, I have requested a svn access to the sandbox for my crypto library. However, I haven't received my e-mail's reply yet. How long should I expect to wait?? With Best Regards Mr. Kasra Nassiri Department of Mathematics & Computer Science Imperial College London

1 0

[build] Using 'distcc' with bjam
by Dean Michael Berris 04 Feb '09

04 Feb '09

Hi Everyone, Has anybody tried using distcc instead of GCC with Boost.Build and Boost.Jam? Thanks in advance. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

2 1

[python] Expose a struct with a std::vector<std::string> member
by Tiago Coutinho 04 Feb '09

04 Feb '09

Hello all, I am new to boost::python. I have access to a C++ library which I want to expose to python using boost. One of the structs I want to expose is something like: #include <vector> struct ExampleStruct { std::vector<std::string> elements; }; I would like to expose this class but I like to avoid having to write a wrapper that would inefficiently have to copy the vector contents to a boost::python::list member. Is there a way to do this? Thank you very much in advance Cheers Tiago

2 4

[mpl]iter_fold_if use of apply1 instead of iter_apply1 maybe bug?
by Larry Evans 04 Feb '09

04 Feb '09

The following code line: https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L… shows apply1<Predicate,Iterator>; however, shouldn't this be iter_apply1<Predicate,Iterators> because, just from the name, Iterator is an iterator and needs to be deref'ed. Also, the previous line: not_< is_same<Iterator,LastIterator> > further suggests that Iterator is actually an iterator. I know it works presently; however, I really don't understand why.

2 1

Any real-world need for static_cast_iterator, const_cast_iterator, dynamic_cast_iterator?
by Nigel Stewart 04 Feb '09

04 Feb '09

In addition to the specialised adaptors in the boost iterator library, does it make any sense to add: static_cast_iterator const_cast_iterator dynamic_cast_iterator ...iterator adaptors providing embedded static_cast<>, const_cast<> or dynamic_cast<> when dereferencing? (Rather than just throwing them straight on the scrap heap...) - Nigel ---------------------------------------------- template<typename T, typename I> class static_cast_iterator : public boost::transform_iterator < T (*)(const typename I::reference), I > { private: typedef typename I::reference F; typedef typename boost::transform_iterator< T (*)(const F), I> B; public: static_cast_iterator() {} static_cast_iterator(const I &i) : B(i,&doCast) {} operator const I &() const { return B::base(); } static_cast_iterator &operator++() { B::operator++(); return *this; } static_cast_iterator &operator--() { B::operator--(); return *this; } private: static T doCast(const F val) { return static_cast<T>(val); } }; template<typename I> class const_cast_iterator : public boost::transform_iterator < typename boost::remove_const<typename I::reference>::type (*)(const typename I::reference), I > { private: typedef typename I::reference F; typedef typename boost::remove_const<F>::type T; typedef typename boost::transform_iterator< T (*)(const F), I> B; BOOST_STATIC_ASSERT(boost::is_const<F>::value); BOOST_STATIC_ASSERT(!boost::is_const<T>::value); public: const_cast_iterator() {} const_cast_iterator(const I &i) : B(i,&doCast) {} operator const I &() const { return B::base(); } const_cast_iterator &operator++() { B::operator++(); return *this; } const_cast_iterator &operator--() { B::operator--(); return *this; } private: static T doCast(const F val) { return const_cast<T>(val); } }; template<typename T, typename I> class dynamic_cast_iterator : public boost::transform_iterator < T (*)(const typename I::reference), I > { private: typedef typename I::reference F; typedef typename boost::transform_iterator< T (*)(const F), I> B; BOOST_STATIC_ASSERT(boost::is_pointer<F>::value || boost::is_reference<F>::value); BOOST_STATIC_ASSERT(boost::is_pointer<T>::value || boost::is_reference<T>::value); public: dynamic_cast_iterator() {} dynamic_cast_iterator(const I &i) : B(i,&doCast) {} operator const I &() const { return B::base(); } dynamic_cast_iterator &operator++() { B::operator++(); return *this; } dynamic_cast_iterator &operator--() { B::operator--(); return *this; } private: static T doCast(const F val) { return dynamic_cast<T>(val); } };

3 5

warnings from gcc-4.3.3 -Wall
by John Salmon 04 Feb '09

04 Feb '09

I recently upgraded to gcc/4.3 and started seeing warnings from gcc-4.3.3 -Wall suggesting parentheses around && within ||. It would be great if boost/1.38 could repair these by adding a few pairs of parentheses before the final release. N.B. I did not do an exhaustive compilation of everything in boost with gcc -Wall. The three cases below are the ones that my code base just happens to hit. Thanks, John Salmon /proj/desres/root/Linux/x86_64/boost/1_37_0-14/Release/include/boost/tuple/tuple_comparison.hpp:73: warning: suggest parentheses around && within || /proj/desres/root/Linux/x86_64/boost/1_37_0-14/Release/include/boost/iostreams/filter/symmetric.hpp:126: warning: suggest parentheses around && within || /proj/desres/root/Linux/x86_64/boost/1_37_0-14/Release/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:285: warning: suggest parentheses around && within ||

2 1