- Boost - lists.boost.org

[move] Unifying move emulation code in boost
by Ion Gaztañaga 06 Jan '09

06 Jan '09

Hi, Howard's unique_ptr contribution has shown again the need for a unified move emulation in Boost. We already have move emulation at least in 5 libraries: -> Interprocess: based on sandbox boost.move library, return types are wrapped in a move_return type. -> Unordered: based on Adobe's move library. It's more advanced than the previous one, but Adobe's own library says (http://stlab.adobe.com/group__move__related.html) that a Movable type must satisfy the requirements of concept Regular, which has copy constructor (thus disabling move-only types!). I don't know if the move emulation itself uses Regular requirements. -> Thread: similar to Howard's unique_ptr move emulation code, user code never sees move_xxx or similar classes. -> Ptr_container: a simple emulation used for static_move_ptr, that could be replaced with a boost::unique_ptr class. -> Variant: MOJO-based emulation (similar to the one used by Interprocess). I think it can be easily replaced with unique_ptr-style emulation. We've been waiting the move library for months, but the fact is that we can't continue having ad-hoc solutions for each library. boost::thread objects must be stored somewhere and unordered containers and boost::interprocess containers are already move-aware. I want to make Intrusive also move-aware but I won't do it until there is some general consensus on what's the common move emulation. I think code changes in boost::thread and boost::unordered would be minimal if we adopt a solution similar to the one used by Howard's unique_ptr. Interprocess changes are heavier but I'm reading to adapt the library to that solution. I've written (attached) a small, surely not complete, but usable boost/move.hpp header (ok, it could go to boost/detail/move.hpp until a decent review is done) that is tested with a movable class in the file movable_test.cpp, both with Visual 7.1 and move-enabled GCC 4.3. The goal of this post is to know if that header file would be enough for all current libraries using move emulation. I have more suggestions (new traits like has_trivial_destructor_after_move<>...) but the main question is if that header can be used to agree a common protocol between us. It would be really nice if we could rework our code for Boost 1.39. If the header contains enough for everyone, I'm ready to write some documentation and tests. I know that this Move library is not what many expect (common macros and utilities to write the same code for rvalue-enabled and older compilers) but I'm afraid entropy has already grown too much ;-) and we can't continue waiting while we add more and more emulation code to Boost. Regards, Ion // Distributed under the Boost Software License, Version 1.0. (See // accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // (C) Copyright 2007-8 Anthony Williams // (C) Copyright 2009 Howard Hinnant // (C) Copyright 2009 Ion Gaztanaga #include <boost/config.hpp> #include <boost/type_traits/is_convertible.hpp> #ifndef BOOST_HAS_RVALUE_REFS #ifndef BOOST_NO_SFINAE #include <boost/utility/enable_if.hpp> #endif #else //#ifndef BOOST_HAS_RVALUE_REFS #include <boost/type_traits/remove_reference.hpp> #endif namespace boost { #include <boost/config/abi_prefix.hpp> #ifndef BOOST_HAS_RVALUE_REFS template<class T> class rv { private: rv &operator=(const rv&); T& r_; public: explicit rv(T& r) : r_(r) {} T* operator->() {return &r_;} T& operator*() {return r_;} }; template<class T> class is_movable { public: static const bool value = boost::is_convertible<T&, rv<T> >::value; }; #ifndef BOOST_NO_SFINAE template<typename T> typename boost::enable_if<boost::is_movable<T>, T>::type move(T& t) { return T(rv<T>(t)); } #endif template<typename T> rv<T> move(rv<T> t) { return t; } #define BOOST_ENABLE_MOVE_EMULATION(TYPE)\ operator boost::rv<TYPE>() \ { return boost::rv<TYPE>(*this); }\ // #define BOOST_SWAP_BASED_MOVE_ASSIGN(TYPE)\ TYPE& operator=(boost::rv<TYPE> r) \ { \ TYPE tmp(r); \ this->swap(tmp); \ return *this; \ } \ // #else //#ifndef BOOST_HAS_RVALUE_REFS #define BOOST_ENABLE_MOVE_EMULATION(TYPE)\ // #define BOOST_SWAP_BASED_MOVE_ASSIGN(TYPE)\ TYPE& operator=(TYPE &&r) \ { \ TYPE tmp(boost::move(r)); \ this->swap(tmp); \ return *this; \ } \ // template <class T> struct move_identity_type { typedef T type; }; template <class T> inline T&& forward(typename boost::move_identity_type<T>::type&& t) { return t; } template <class T> inline typename boost::remove_reference<T>::type&& move(T&& t) { return t; } template <class T, class U> class move_is_convertible { typedef char true_t; class false_t { char dummy[2]; }; static true_t dispatch(U); static false_t dispatch(...); static T trigger(); public: enum { value = sizeof(dispatch(trigger())) == sizeof(true_t) }; }; template<class T> class is_movable { public: static const bool value = move_is_convertible<T&&, T>::value; }; #endif //#ifndef BOOST_HAS_RVALUE_REFS #include <boost/config/abi_suffix.hpp> } //namespace boost {

6 15

Re: [boost] Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 05 Jan '09

05 Jan '09

>> BTW: After long and honorable service, Tom stepped down as a review >> wizard a bit more than a year ago. I'm sure he would have plenty to >> offer if he wanted it back, but as far as I know, he hasn't asked to be >> re-appointed. Thanks John. Its great that you volunteered to be the Wizard. I still regularly follow the boost newsgroup, so let me know if there is anything that you need.

1 0

[future William proposal] packaged_task do not accept boost::ref of a nullary functor
by vicente.botet 05 Jan '09

05 Jan '09

Hi, packaged_task do not accept boost::ref to nullary functions while thread allows it. Shouldn't packaged_task accept them? How can the user workaround this issue? How thread solved this issue? Thanks in advance, Vicente ===================== Compiler error: ../../../../boost/futures/future.hpp: In member function `void boost::detail::task_object<R, F>::do_run() [with R = int, F = boost::reference_wrapper<non_copyable_functor>]': test.cpp:250: instantiated from here ../../../../boost/futures/future.hpp:1206: error: no match for call to `(boost::reference_wrapper<non_copyable_functor>) ()' ===================== Here it is the code: struct non_copyable_functor : boost::noncopyable { unsigned value; typedef unsigned result_type; non_copyable_functor(): value(0) {} unsigned operator()() { value=999; return value; } }; void do_test_creation_through_reference_wrapper() { non_copyable_functor f; boost::packaged_task<unsigned > tsk(boost::ref(f)); tsk(); // COMPILER ERROR HERE //boost::future<unsigned > act = tsk.get_future(); //boost::thread thr(boost::move(tsk)); //unsigned res = act.get(); //BOOST_CHECK_EQUAL(res, 999u); //BOOST_CHECK_EQUAL(f.value, 999u); } _____________________ Vicente Juan Botet Escribá

2 4

[future] review starts today?
by k-oli＠gmx.de 05 Jan '09

05 Jan '09

Does the review start officialy today (5. January)? Between the announcement and the 5. January a lot of posts arrived the mailing list. Oliver

1 0

Re: [boost] [crypto] Finalisation
by Kasra 05 Jan '09

05 Jan '09

Dear Kevin, I didn't know you were working on your library I thought you have coded one and decided it was enough for your needs and had stopped developing. So if we are both developing I personally think it is more than silly to code two separate libraries instead of focusing on one. If you are interested we could merge the current progress into 1 library. In regards to your comment about the amount of code, I have the following algorithms fully functioning (some need little attention): BlockCiphers: Blowfish, Cast-256, Khazad, Mars, Rijndael, RC2, RC5, RC6, Serpent, Twofish All of the above implementations are generic, for example rc6 is defined as follows: template < size_t R, // # of rounds typename W // word size {uint8_t,uint16_t,uint32_t,uint64_t} > class rc6_cipher; // the recommended rc6, although completely generic // but the following typedef could gain performance of // 26 Clocks Per Byte (CPB) which is _almost_ as fast as it gets typedef rc6_cipher<20,32> rc6; StreamCiphers: RC4, HC-128/256, Rabbit, Salsa, Sosemanuk Hash Functions: MD4, MD5, SHA-1, SHA-244, SHA-256, SHA-384, SHA-512, Whirlpool, (ifdef BOOST_CRYPTO_EXPERIMENTAL) { MD6, Sekin } Padding: One-zero, ISO-10126, PKCS-7. Mode Of operation: ECB, CBC, OFB, CFB, CTR-E, CTR-D, LRW, XTS mode of operations is something like: template < BlockCipher BlockCipherT, PaddingAlgorithm PaddingAlgorithmT > class XTS; Also endian class which is designed to read/write correct endian values from/to memory. I haven't implemented Public key cryptography because of not having a clear answer to what library to use for large number operations, or for example implement internal library for it. With Best Regards Kasra

2 1

[Reviews] Futures - packaged_task and shared_future
by vicente.botet 05 Jan '09

05 Jan '09

Hi, can you consider the ability of a shared_packaged_task to return a shared_future? This is a temporary use case until we have implementation of containers allowing movable_only object. unique_future<T> is movable_only and can not be stored on current containers as for example fusion::tuple. Best, Vicenre _____________________ Vicente Juan Botet Escribá

2 2

[date_time] SIGSEGV in multithreaded code on Solaris Sparc
by Roberto Gimenez 05 Jan '09

05 Jan '09

The following multithreaded code causes SIGSEGV in Solaris Sparc 10: #include <boost/thread.hpp> #include <sstream> #include <boost/date_time/posix_time/posix_time.hpp> using namespace std; using namespace boost; void fun(); int main(int argc, char** argv) { thread t1(fun); thread t2(fun); pause(); return (EXIT_SUCCESS); } void fun() { while(true) { stringstream str; str << posix_time::microsec_clock::local_time().time_of_day(); } } The stackstrace from the core dump is the following: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ead3c50 _pause (ffffffff7ffff4e0, ffffffff7ee00200, 0, ffffffff7ef08ba4, ffffffff7e300140, 0) + 8 0000000100015ea0 main (1, ffffffff7ffff5f8, ffffffff7ffff608, ffffffff7ea4aedc, ffffffff7e3000c0, ffffffff7ee00200) + 58 000000010001589c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ea3b670 strlen (ffffffff7e0fba38, 1001377c0, 1, ffffffff7f510d00, c, ffffffff7f51d608) + 50 0000000100017c60 std::locale::locale<boost::date_time::time_facet<boost::posix_time::ptime,char, std::ostreambuf_iterator<char,std::char_traits<char>> > >#Nvariant 1(const std::locale&,__type_0*) (ffffffff7e0fba38, ffffffff7e0fba30, 1001362a0, 1061b4, ffffffff7f00ef70, 1) + 68 000000010001728c std::basic_ostream<__type_0,__type_1>&boost::posix_time::operator<<< char,std::char_traits<char>>(std::basic_ostream<__type_0,__type_1>&,const boost::posix_time::time_duration&) (ffffffff7e0fbbb0, ffffffff7e0fbb90, ffffffff7e0fbbb8, ffffffff7e0fbd08, ffffffff7f51a160, ffffffff7f510d00) + 22c 0000000100015f84 void fun() (ffffffff7f915528, 10012f920, 3, ffffffff7ee00b58, 18, 3) + 5c 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (10012f920, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (10012f920, 2, 10012de88, 10012f920, 3, 48) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- ffffffff7f3d3130 std::locale::~locale #Nvariant 1() (ffffffff7f915528, 1001311f0, 3, ffffffff7ee01358, 18, 3) + 8 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (1001311f0, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (1001311f0, 2, 10012df30, 1001311f0, 3, 5d) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) When running with just one thread, it works fine. So it's a race condition aparently. The stacktrace varies. This is another one: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ead3c50 _pause (ffffffff7ffff4e0, ffffffff7ee00200, 0, ffffffff7ef08ba4, ffffffff7e300140, 0) + 8 0000000100015ea0 main (1, ffffffff7ffff5f8, ffffffff7ffff608, ffffffff7ea4aedc, ffffffff7e3000c0, ffffffff7ee00200) + 58 000000010001589c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7f3d3130 std::locale::~locale #Nvariant 1() (ffffffff7f915528, 10012f920, 3, ffffffff7ee00b58, 18, 3) + 8 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (10012f920, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (10012f920, 2, 10012de88, 10012f920, 3, 48) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- 000000010001e090 unsigned long boost::date_time::gregorian_calendar_base< boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month,boost::gregorian::greg_day>, unsigned long>::day_number(const boost::date_time:: year_month_day_base<boost::gregorian::greg_year,boost::gregorian:: greg_month,boost::gregorian::greg_day>&) (ffffffff7defb7c4, 7d9000000000000, 1000000000000, 5000000000000, 4, 7d9) + 1b8 000000010001b078 boost::date_time::date<boost::gregorian::date, boost::gregorian::gregorian_calendar,boost::date_time::date_duration< boost::date_time::duration_traits_adapted> >::date #Nvariant 1( boost::gregorian::greg_year,boost::gregorian::greg_month, boost::gregorian::greg_day) (ffffffff7defb9b0, 7d9000000000000, 1000000000000, 5000000000000, ffffffff7ebf6c38, ffffffff7defb9c0) + 98 000000010001a3a0 boost::gregorian::date::date #Nvariant 1(boost::gregorian:: greg_year,boost::gregorian::greg_month,boost::gregorian::greg_day) (ffffffff7defb9b0, 7d9000000000000, 1000000000000, 5000000000000, 400, ffffffff7defb9f0) + 90 0000000100017a20 boost::posix_time::ptime boost::date_time::microsec_clock< boost::posix_time::ptime>::create_time(boost::date_time:: microsec_clock<boost::posix_time::ptime>::TZ_FOR_CREATE) (0, 1000, 6, 0, 198704, 18) + 128 000000010001749c boost::posix_time::ptime boost::date_time::microsec_clock< boost::posix_time::ptime>::local_time() (ffffffff7defbba0, 18, ffffffff7defbbb8, ffffffff7defbd08, ffffffff7f51a160, ffffffff7f510d00) + c 0000000100015f40 void fun() (ffffffff7f915528, 1001311f0, 3, ffffffff7ee01358, 18, 3) + 18 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (1001311f0, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (1001311f0, 2, 10012df30, 1001311f0, 3, 5d) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) The only constant thing is the deletion of the locale: std::locale::~locale Compiler is: CC: Sun C++ 5.9 SunOS_sparc Patch 124863-07 2008/08/22 Any clues?

1 0

boost.org: Minor nitpick
by dhruva 05 Jan '09

05 Jan '09

Hi, The following link is supposed to list the header-only packages first (more intuitive) but lists the auto-link packages first. http://www.boost.org/doc/libs/1_37_0?sort=header-only -dhruva -- Contents reflect my personal views only!

3 2

[thread] thread_proxy's catch(...) destroys my stack info for unhandled exceptions
by Roberto Gimenez 05 Jan '09

05 Jan '09

When some unhandled exception is thrown inside my function, it would be good that is isn't actually handled, so I could collect the stack info from the core-dump. For example: #include <boost/thread.hpp> using namespace std; using namespace boost; void f1() { throw 1; } void f2() { throw 1; } void f() { f1(); f2(); } int main(int argc, char** argv) { thread t(f); t.join(); return (EXIT_SUCCESS); } Whe run it, the core-dump's stack info is: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ecd2f20 __lwp_park (100108658, 100108640, ... ffffffff7eccc748 cond_wait_queue (100108658, 100108640, ... ffffffff7ecccca8 cond_wait (100108658, 100108640, ... ffffffff7ecccce4 pthread_cond_wait (100108658, 100108640,... ffffffff7f809ff4 void boost::thread::join() (ffffffff7ffff518, ... 0000000100004168 main (1, ffffffff7ffff608, ffffffff7ffff618, ... 0000000100003a7c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ecd40a4 _lwp_kill (6, 0, ffffffff7edf7338, ... ffffffff7ec4a68c abort (1, 1b8, ffffffff7f106f10, ... ffffffff7f106a04 void __Cimpl::default_terminate() (0, 0, ... ffffffff7f809770 thread_proxy (100108610, 1001086dd, 2c, ... ffffffff7ecd2e7c _lwp_start (0, 0, 0, 0, 0, 0) With this information I cannot know where the exception was thrown. So I commented the catch(...) part in libs/thread/src/pthread/thread.cpp: extern "C" { void* thread_proxy(void* param) { boost::detail::thread_data_ptr thread_info = static_cast<boost::detail::thread_data_base*>(param)->self; thread_info->self.reset(); detail::set_current_thread_data(thread_info.get()); try { thread_info->run(); } catch(thread_interrupted const&) { } //catch(...) //{ // std::terminate(); //} detail::tls_destructor(thread_info.get()); detail::set_current_thread_data(0); boost::lock_guard<boost::mutex> lock(thread_info->data_mutex); thread_info->done=true; thread_info->done_condition.notify_all(); return 0; } } And recompiled boost, now the core dump's stack info is the desired one: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ecd2f20 __lwp_park (100108658, 100108640, 0, 4, 11fb1c, ... ffffffff7eccc748 cond_wait_queue (100108658, 100108640, 0, 0, ... ffffffff7ecccca8 cond_wait (100108658, 100108640, ffffffff7ed00358,... ffffffff7ecccce4 pthread_cond_wait (100108658, 100108640, ... ffffffff7f809f54 void boost::thread::join() (ffffffff7ffff518, ... 0000000100004168 main (1, ffffffff7ffff608, ffffffff7ffff618, ... 0000000100003a7c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ecd40a4 _lwp_kill (6, 0, ffffffff7edf7338, ... ffffffff7ec4a68c abort (1, 1b8, ffffffff7f106f10, ... ffffffff7f106a04 void __Cimpl::default_terminate() (ffffffff7f214718, ... ffffffff7f1067f4 void __Cimpl::ex_terminate() (ffffffff7f2106c0, 0, 0, ... ffffffff7f1074c8 _ex_throw_body (ffffffff7f2106c0, 0, ffffffff7e2fbf50, ... ffffffff7f10740c void __Crun::ex_throw(void*,... 0000000100004064 void f1() (0, 0, ffffffff7edf7f80, ... 00000001000040fc void f() (ffffffff7f915528, 100108610, ... 00000001000053c0 void boost::detail::thread_data<void(*)()>::run() (... ffffffff7f8095b4 thread_proxy (100108610, 3, 100106bd8, 100108610... ffffffff7ecd2e7c _lwp_start (0, 0, 0, 0, 0, 0) I can know now where the unexpected/unhandled exception was thrown. I could solve my problem partially, puting throw() exception specs everywhere, so when some unexpected exception is thrown, the throw() will stop it. Unfortunatelly, it whould stop at the calling function, and the stack will tell me that some unexpected exception was thrown by any of the functions inside the caller. This is worse than having a stack info like the above one because in this case I wouldn't know who raised the unexpected exception. In the above stack info I can know who did it. So why is: catch(...) { std::terminate(); } there? It looks unnecesary.

5 9

How to access COM ports
by master master 05 Jan '09

05 Jan '09

How to access COM port using BOOST library. I want to access COM3 port using boost. For socket port the below line works .... ........ boost::asio::ip::tcp::resolver::query query("localhost", "9999"); .......... ..... but how to do it for COM port I tried this .... ....... boost::asio::ip::tcp::resolver::query query("localhost", "COM3"); ......... ....... but it didn't worked. Another problem I am facing is that the network client should be platform-independent but if I use socket.h then it will not work on windows and if I use winsock then it will not run on linux/unix variants. Same for other header files like inet.h etc Rahul To create something exceptional ________________________________ -Master4Master "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email, and delete this message and any attachments from your system. Virus Warning: Although I have taken reasonable precautions to ensure no viruses are present in this email, I cannot accept responsibility for any loss or damage arising from the use of this email or attachment." Speak out for justice and peace, even if your voice trembles. Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

3 4