- Boost - lists.preview.boost.org

Re: [boost] [variant]compile-time-checked boost::get<T>?
by Arno Schödl 06 Jan '09

06 Jan '09

Hello, would anyone object to changing the semantics of boost::get to do the compile time check, rather than introducing a boost::checked_get? I think changing the semantics is o.k., at least if the first version does not allow casts. If existing code does not compile, it can be fixed by a) replacing the boost::get with a NULL constant or a throw statement, b) or, if the code is generic (and I doubt there is such code), with a compile-time check, and for the case of a type not contained in the variant, using a). I think changing the semantics may reveal more unknown bugs than unnecessarily break code. 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

2 1

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

06 Jan '09

>> Are we reviewing both libraries at once? That is my understanding. However, at this point, until persuaded otherwise, I'm inclined to suggest to both authors that they should find a way to work together and issue a joint release. I've looked at both libraries and the differences are subtle. Maybe we just need to persuade them that it would not diminish their work in any way if they were to submit a joint release. As both submissions are of high quality, I would not want to discourage either author. It would also seem to me that the logging library proposals have the same problem. It would be my hope that we could get the authors of the various logging library proposals to work together and issue a joint release as well. One could dream.

3 3

XML Digester
by Themis Vassiliadis 06 Jan '09

06 Jan '09

Hi All, I'm finishing a preliminary version of a class with similar behavior like Java Digester. In this class the developer defines triggers witch will be fired when specific tags are found from XML file. Let me explain better with an example: A simple approach will be to use the following Digester in the following way to set up the parsing rules, and then process an input file containing this document: digester = new boost::xml_digester::xml_digester((std::istream*)&st); digester->setValidating( false ); digester->addObjectCreate<classFoo>("foo"); digester->addObjectCreate<classBar>("foo/bar"); digester->addCallMethod<classBar>("foo/bar/prop1", &classBar::setProp1); digester->addSetProperty<classBar>("foo/bar/prop2", &classBar::prop2); digester->addSetNext<classFoo>("foo/bar", &classFoo::addBar); digester->parse(); .... class classBar { std::string prop1; public: std::string prop2; void setProp1(std::string value) { prop1 = value; } }; class classFoo { std::vector<classBar*>obj_bars; public: void addBar(void *instance) { obj_bars.push_back((classBar*)instance); } }; XML: <?xml version='1.0' encoding='UTF-8'?> <foo> <bar> <prop1>xxxxxx</prop1> <prop2>yyyyyy</prop2> </bar> <bar> <prop1>zzzzzz</prop1> <prop2>kkkkkk</prop2> </bar> </foo> In order, these rules do the following tasks: 1. When a nested <foo> element is encountered, create a new instance of "classFoo" and push it on to the object stack. At the end of the <foo> element, this object will be popped off of the stack. 2. When a nested <bar> element is encountered, create a new instance of "classBar" and push it on to the object stack. At the end of the <bar> element, this object will be popped off of the stack (i.e. after the remaining rules matching foo/bar are processed). 3. Cause method setProp1 of class "classBar" to be called each time "prop1" is loaded. A std::string type parameter is passed as the value. 4. Cause property "prop2" of class "classBar" to be set each time "prop2" is loaded. The property must have public scope and its type must be std::string. 5. Cause the "addBar" method of class "classFoo" to be called, passing the instance of "classBar" created in the step 2. This rule allow to establish a parent/child relationship between "classFoo" and "classBar". I think that with these features the developer might do everything that he need to parse XML files to objects in 90% of cases. Of course the Java Digester is more powerful and complex and for next releases we can improve it. Regards, -- Themis Vassiliadis

3 3

[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

BoostCon 2009: Call for participation
by Hartmut Kaiser 04 Jan '09

04 Jan '09

Hi all, Please find below the call for participation for the 3rd annual Boost Conference in Aspen. There are only a couple of days left to submit any proposals. I'm sorry for any duplicates you might receive. Please forward this mail to any related mailing list or any person you think might be interested. Regards Hartmut ---------------------------------------------------------------------------- 3rd annual Boost Conference 2009 Aspen CO, USA, May 3-9, 2009, www.boostcon.com ---------------------------------------------------------------------------- Call for participation ---------------------- Promising to be the main face-to-face event for all things Boost (www.boost.org) BoostCon'09 opens the door to your C++ future. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2 and the new C++0x Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- * Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * TR1 and TR2 * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and Developers. Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations ............. Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ...... Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ......... Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ......... Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ............................. These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems boost libraries. Tool Vendors Presentations .......................... We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other * A paragraph or two describing the topic covered, suitable for the conference web site * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half-day, full day * Alternate lengths, if you are willing to make adjustments: 10-20 minute lightning-talks, 45 minutes, 90 minutes, half-day, full day * Audience: users, developers, both * Level: basic, intermediate, advanced * A biography, suitable for the conference web site * Your contact information (will not be made public) Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon09. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted papers will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon CD handed out to attendees. For general information on the BoostCon 2009 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon09(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposals for submissions due: January 10th 2009. Proposals acceptances sent (tentative program available): February 10th, 2009 Fully scheduled program available: March 1st, 2009 Session materials due: April 1st 2009. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

Re: [boost] [logging] Interest check on logging library.
by Jason Wagner 04 Jan '09

04 Jan '09

Andrey Semashev wrote: > Sorry, couldn't resist. I think, my library fits these requirements > quite well. Why would you start your own implementation from scratch? Is > there something that doesn't suit you in my implementation? It started because I thought yours was no longer in development. I have no idea why I thought that, since looking at your cvs logs you have been consistently working on it. It was largely a mistake. I'm writing a internet spaceship game. There's a client and a cluster of servers with different types. The protocol is simple message passing, with the serialization code shared between client and server. This leads to a very simple example like: if(message.size > packet.size) { log << severity::warn() << "Packet was larger than the buffer that contains it!" << build_target::server() << " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); // error handling } On the client side, we note that the packet was too big and move on. On the server side, we actually log the packet since evil hackers are always trying to steal my space bucks. Since the template generates empty code at compile time, both gcc and msvc are smart enough to remove the " Packet source=" and ", account= " strings from the binary, providing less clue in the client as to what the server is watching for. On the server side, I probably want this record to go into a database, so having the entire thing as a single record is very important. That precludes items of the form: log << severity::warn() << "..."; if(server) // or #ifdef log << "Packet source = "; //... I also really don't like having the conditional in the logging. Looking at the serialization code, one shouldn't have to wade through the logic of logging. I think I could add this to your library using features. That's not a light weight thing to add, based upon what I see features need to be instantiated. In my scheme, since the if() test is built into the log record instantiation there's single point to change to affect all appropriate loggers. With your scheme I'd have to change the logger type, the if()s that wrap them or the macros that contain the ifs, and possibly client code as well. Switching to a different scheme, I could do: log << severity::warn() << "Packet was larger than the buffer that contains it!" << auditing::full() << " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); Now, on the client side I can turn off full auditing at compile time and on the server time I can turn off packet logging at run time and have a condition that turns it on when I suspect a problem. There is a separation of concerns between what audit level and severity of the record. The whole thing could be rewritten with scope variables for connection and user that would allow them to be first class denizens of the database or fed into an event processing system without having to do entity extraction on the record. In addition, immediately insertable variables prevent the overhead of setting scope variables if not needed: log << severity::warn() << "Packet was larger than the buffer that contains it!" << auditing::full() << << set("User", user) << set("connection",connection) " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); --- Jason Wagner jason(a)nialscorva.net

4 8

[exception]throw_exceptions concerns
by Gennadiy Rozental 04 Jan '09

04 Jan '09

Hi, I am trying to look closely on to the warnings emitted during Boost.Test compilation and I've noticed couple that makes me a bit concerned (these are from msvc-7.1 toolset): ..\..\..\boost\throw_exception.hpp(58) : warning C4673: throwing 'boost::exception_detail::clone_impl<T>' the following types will not be considered at the catch site with [ T=boost::exception_detail::enable_error_info_return_type<boost::bad_weak_ptr>::type ] ..\..\..\boost\detail\shared_count.hpp(407) : see reference to function template instantiation 'void boost::throw_exception<boost::bad_weak_ptr>(const E &)' being compiled with [ E=boost::bad_weak_ptr ] ..\..\..\boost\throw_exception.hpp(58) : warning C4671: 'exception' : the copy constructor is inaccessible Here is the list of my concerns: 1. What does the first one means and should we worry? 2. Does the second means that std::exception is not copy constructible? If yes can we disable it inside the header? 3. These warnings seems to be originated from the lines related to the Boost.Exception. in this regard I've got following concerns: a) Was it agreed that practically all Boost users are now exposed to the Boost.Exceptions library by default whether they are willing or not b) throw_exception documentation is now incorrect and misleading, since it does not mention this 4. If let's say I would like to disable Boost.Exceptions exposure during Boost.Test compilation, will it lead to the ODR violations? Thanks, Gennadiy

3 5

segemented iterator support?
by k-oli＠gmx.de 04 Jan '09

04 Jan '09

Does boost support a kind of segemented iterator (Segmented Iterators and Hierarchical Algorithms, Matthew H. Austern)? Oliver

3 4

Boost::serialization pointer bug
by Ross Levine 04 Jan '09

04 Jan '09

Hi all, I think I've found a bug in boost::serialization. If I change the order of serialization, one of my pointers does not seem to be correctly serialized. It's hard to explain, so please see my code: http://dl.getdropbox.com/u/416909/serialization_error.cpp and http://dl.getdropbox.com/u/416909/simple_tree.hpp I'm using VS2008. Thanks, Ross

1 0

Can't access ticket?
by John Maddock 03 Jan '09

03 Jan '09

Can anyone access this ticket: https://svn.boost.org/trac/boost/ticket/764 ? It's assigned to me, but IE and Firefox return an internal Trac error: Trac detected an internal error: TypeError: a float is required Python Traceback Most recent call last: File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/web/main.py", line 423, in _dispatch_request Code fragment:try:if not env and env_error:raise HTTPInternalError(env_error)try:dispatcher = RequestDispatcher(env)dispatcher.dispatch(req)except RequestDone:passresp = req._response or []except HTTPException, e:Local variables:NameValueafter[u' except RequestDone:', u' pass', u' resp = ...before[u' try:', u' if not env and env_error:', u' raise ...dispatcher<trac.web.main.RequestDispatcher object at 0xb7aff90c>e<exceptions.TypeError instance at 0xb7a6874c>env<trac.env.Environment object at 0xb7c46aec>env_errorNoneexc_info(<class exceptions.TypeError at 0xb7f782cc>, <exceptions.TypeError ...filename'/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/web/main.p ...frames[{'function': '_dispatch_request', 'lines_before': [u' try:', u' ...has_adminTruelineu' dispatcher.dispatch(req)'lineno422messageu'TypeError: a float is required'req<Request "GET u'/ticket/764'">resp[]tb<traceback object at 0xb7a6e324>tb_hideNonetraceback'Traceback (most recent call last):\n File ...File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/web/main.py", line 197, in dispatch Code fragment:req.args.get('__FORM_TOKEN') != req.form_token:raise HTTPBadRequest('Missing or invalid form token. ''Do you have cookies enabled?')# Process the request and render the templateresp = chosen_handler.process_request(req)if resp:if len(resp) == 2: # Clearsilverchrome.populate_hdf(req)template, content_type = \self._post_process_request(req, *resp)Local variables:NameValuechosen_handler<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>chrome<trac.web.chrome.Chrome object at 0xb7c65d6c>err(<class exceptions.TypeError at 0xb7f782cc>, <exceptions.TypeError ...handler<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>req<Request "GET u'/ticket/764'">self<trac.web.main.RequestDispatcher object at 0xb7aff90c>File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/web_ui.py", line 152, in process_request Code fragment:def process_request(self, req):if 'id' in req.args:if req.path_info.startswith('/newticket'):raise TracError(_("id can't be set for a new ticket request."))return self._process_ticket_request(req)return self._process_newticket_request(req)# ITemplateProvider methodsdef get_htdocs_dirs(self):Local variables:NameValuereq<Request "GET u'/ticket/764'">self<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>File "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/web_ui.py", line 412, in _process_ticket_request Code fragment:version = int(version)except ValueError:version = Nonereq.perm('ticket', id, version).require('TICKET_VIEW')ticket = Ticket(self.env, id, version=version)action = req.args.get('action', ('history' in req.args and 'history' or'view'))data = self._prepare_data(req, ticket)data['comment'] = NoneLocal variables:NameValueid764req<Request "GET u'/ticket/764'">self<trac.ticket.web_ui.TicketModule object at 0xb7aff96c>versionNoneFile "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/model.py", line 47, in __init__ Code fragment:self.env = envself.resource = Resource('ticket', tkt_id, version)self.fields = TicketSystem(self.env).get_ticket_fields()self.values = {}if tkt_id is not None:self._fetch_ticket(tkt_id, db)else:self._init_defaults(db)self.id = self.time_created = self.time_changed = Noneself._old = {}Local variables:NameValuedbNoneenv<trac.env.Environment object at 0xb7c46aec>self<trac.ticket.model.Ticket object at 0xb7affe0c>tkt_id764versionNoneFile "/opt/trac2/lib/python2.4/site-packages/Trac-0.11-py2.4.egg/trac/ticket/model.py", line 105, in _fetch_ticket Any ideas anyone? Thanks, John.

4 7

[crypto] Finalisation
by Kasra 03 Jan '09

03 Jan '09

Dear Kevin Sopp, I know you are interested in this library I have looked at your code and have decided to use considerable amount of your library's concepts. Dear All, You may know that I have been working on a crypto library for boost. I think at this time the design and concepts for the library is finished and implementation could be started. However, I decided to check with interested parties before I begin the implementation. Currently the concepts is as follows: [Note] C++0x features has been used but there is a work around library which allows pre-C++0x compilers to compile the code. auto concept BlockCipherTraits { enum cipher_type { feistle, substitution_permutation, square, }; static constexpr size_t block_size; static constexpr size_t min_key_size; static constexpr size_t max_key_size; static constexpr cipher_type type(); static constexpr bool timming_attack_resistant; }; template<typename T=byte_t> auto concept PaddingTraits { static constexpr size_t block_size; static constexpr size_t min_block_size; /* = sizeof(T) * 2; */ static constexpr size_t max_block_size; /* = detail::pow<2,sizeof(T)*8>::value; */ static constexpr const char* name(); }; class crypto_exception; class cipher_state; class invalid_length; class invalid_key_size; class invalid_iv_size; class bad_padding; template<typename T> auto concept Padding requires PaddingTraits<T> { typename size_type; typename value_type; static constexpr size_t output_size(size_t ); static constexpr size_t pad(value_type* output, const value_type* input, size_t input_size) throw(invalid_length); static constexpr size_t unpad(value_type* output, const value_type* input, size_t input_size) throw(bad_padding); }; template<typename T> auto concept BlockCipher { typename value_type; typename size_type; const void setkey(const value_type* key, size_type key_size) throw(invalid_key_size); const void encrypt(value_type* ctxt, const value_type* ptxt); const void decrypt(value_type* ptxt, const value_type* ctxt); }; template<typename T = byte_t> auto concept StreamCipherTraits { typename value_type; static constexpr size_t min_stream_size; static constexpr size_t max_stream_size; static constexpr size_t transform_size; static constexpr size_t min_key_size; static constexpr size_t max_key_size; static constexpr size_t min_iv_size; static constexpr size_t max_iv_size; static constexpr bool seekable_stream; static constexpr bool synchronous; static constexpr bool asynchronous; }; template<StreamCipherTraits StreamCipherT> auto concept StreamCipher : StreamCipherT { typedef value_type; typedef StreamCipherT traits_type; const void setkey(const value_type* key, size_type key_size) throw(invalid_key_size); const void setivconst value_type* iv, size_type iv_size) throw(invalid_iv_size); const void encrypt(value_type* output, const value_type* input, size_type input_size); const void decrypt(value_type* output, const value_type* input,size_type input_size); }; // mode of operation + block cipher == stream_cipher template<typename T=byte_t, BlockCipher Cipher> auto concept ModeOfOperation: public StreamCipher { typedef Cipher block_cipher_type; }; template<typename T=byte_t> auto concept HashFunctionTraits: StreamCipherTraits { static constexpr size_t transform_size; static constexpr size_t digest_size; }; template<typename T=byte_t, HashFunctionTraits HashFunctionT> auto concept HashFunction : public HashFunctionT { typedef HashFunctionT traits_type; size_t digest_size() const; constexpr create(); template<size_t N> constexpr update(const crypto_buffer_t<N>& input); constexpr finalise(); template<size_t N> constexpr compute(crypto_buffer_t<traits_type::digest_size>& digest, const crypto_buffer_t <N>& input); }; class crypto_streambuf; class crypto_istream; class crypto_ostream; class crypto_iostream; Also I would like to make this library compatible with boost.iostream so that an encryption algorithm could be used as a filter for the boost.iostream. The library tries to do most of the computation at compile time. I would welcome all comments. With Best regards Kasra

2 1

[accumulators] rolling mean
by Eric Niebler 03 Jan '09

03 Jan '09

The accumulators library now has a handful of rolling accumulators, including a rolling sum and a rolling mean. These have been on trunk for about a week, and have recently been merged to release and will be part of the 1.38 release. Enjoy, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

Is there any interest in Asynchronous Executors and Asynchronous Completion Token library
by vicente.botet 02 Jan '09

02 Jan '09

Hi, I'm playing with some asynchronous executors and want to know if there is an interest in a library that work with Asynchronous Executors (AE) and Asynchronous Completion Tokens (ACT) in a generic way (or atleast this was my intention). The library can be considered as a front-end for several Asynchronous Execution models making it possible to share common algorithms and making easier to switch from an Asynchronous Executors to another. For the moment I have included it in my Bosst.InterThreads library (bith=boost::interthreads), but this is independent and can be included in an independent library (any suggestion for a name and a namespace?) Next follows the motivation for the library and how the library manage with this concepts. Of couse any comments are welcome. In N1833 - Preliminary Threading Library Proposal for TR2 Kevlin Henney introduce the concept of threader and a function thread that evaluate a function asynchronously and returns a joiner handle. In N2185 - Proposed Text for Parallel Task Execution Peter Dimov introduce a fork function able to evaluate a function asynchronously and returns a future handle. In N2276 - Thread Pools and Futures Anthony William introduce launch_in_thread and launch_in_pool function templates which evaluate a function asynchronously either in a specific thread or a thread pool and returns a unique_future handle. In Boost.ThreadPool Oliver Kowalke propose a complete implementation of a thread pool with a submit function which evaluate a function asynchronously and returns a task handle. Behind all these proposal there is a concept of asynchronous executor, fork-launch-like function and the asynchronous completion token handle. Name executor fork-like ACT Boost.Thread ?? thread constructor thread Boost.ThreadPool tp::pool submit tp::task N2276 thread launch_in_thread unique_future<T> N2276 thread_pool launch_in_pool unique_future<T> N2185 ?? fork future<T> N1833 threader thread joiner<T> The asynchronous completion token models can follows two interfaces, the thread interface and the unique_future interface. Some asynchronous completion token handles allows to recover the result of the evaluation of the function (futures), other allows to manage the underlying thread of execution (thread) and some both (joiner and tp::task). It seems natural to make a generic fork function that will evaluate a function asynchronously with respect to the calling thread and returns an ACT handle. The following metafunction associated an ACT handle to a asynchronous executor. template <typename AE, typename T> struct asynchronous_completion_token { typedef typename AE::handle<T>::type type; }; The result of forking a nullary function by an asynchronous executor is given by the following metafunction: namespace result_of { template <typename AE,typename F> struct fork { typedef typename asynchronous_completion_token<AE, typename result_of<F()>::type>::type type; }; } The default implementation of fork delegates on fork asynchronous executor function. template< typename AE, typename F > result_of::fork<AE, F>::type fork( AE& ae, F fn ) { return ae.fork(fn); } Forking n-ary functions relies on the nullary version and bind. template< typename AE, typename F, typename A1, ..., typename An > asynchronous_completion_token<AE, typename result_of<F(A1,..., An)>::type >::type fork( AE& ae, F fn, A1 a1, ..., An an ) { return ae.fork( bind( fn, a1, ..., an ) ); } We can define a basic_threader which just returns a new thread as follows: class basic_threader { public: template <typename T> struct handle { typedef boost::thread type; }; template <typename F> boost::thread fork(F f) { thread th(f); return boost::move(th); } }; The library includes a launcher class that creates a thread and returns a unique_future when forking. class launcher { public: template <typename T> struct handle { typedef unique_future<T> type; }; template <typename F> unique_future<typename result_of<F()>::type> fork(F f) { typedef typename result_of<F()>::type result_type; packaged_task<result_type> tsk(f); unique_future<result_type> res = tsk.get_future(); thread th(boost::move(tsk)); return res; } }; Given the sequential example (taken from N2185) double f( double a, int n ) { double r = 0.0; for( int i = 1; i <= n; ++i ) { double x = 1.0 / i; r += std::pow( x, a ); } return r; } int main() { double m1 = f( 1.0, 1000000 ); double m2 = f( 1.0, 5000000 ); double m3 = f( 2.2, 1000000 ); double m4 = f( 2.2, 5000000 ); std::cout << m2 - m1 + m3 - m4 << std::endl; } this library allows a programmer to switch to parallel execution as follows: int main() { launcher l; boost::unique_future<double> fm1 = bith::fork( l, f, 1.0, 1000000 ); boost::unique_future<double> fm2 = bith::fork( l, f, 1.0, 5000000 ); boost::unique_future<double> fm3 = bith::fork( l, f, 2.2, 1000000 ); boost::unique_future<double> fm4 = bith::fork( l, f, 2.2, 5000000 ); std::cout << fm2.get() - fm1.get() + fm3.get() - fm4.get() << std::endl; } The library include also a threader class based on the Kevlin proposal: class threader { public: template <typename T> struct handle { typedef joiner<T> type; }; template <typename F> joiner<typename result_of<F()>::type> fork(F f) { typedef typename result_of<F()>::type result_type; return joiner<result_type>(f); } }; The question now is how we can adapt it to an existing asynchronous executor such as the Boost.ThreadPool library. We need to specialize the template class asynchronous_completion_token template <typename Channel, typename T> struct asynchronous_completion_token<boost::tp::pool<Channel>,T> { typedef boost::tp::task<T> type; }; and function fork function template< typename Channel, typename F > result_of::fork<boost::tp::pool<Channel>, F>::type fork<boost::tp::pool<Channel>,F>( boost::tp::pool<Channel>& ae, F fn ) { return ae.submit(fn); } Note that the single fork function that needs specialization is the one taking a nullary function as parameter. We can write the preceding main function in a more generic way template < typename AE> void doit(AE& ae) { bith::result_of::fork<AE, f, tuple<double, int> >::type fm1 = bith::fork(ae, f, 1.0, 1000000 ); bith::result_of::fork<AE, f, tuple<double, int> >::type fm2 = bith::fork(ae, f, 1.0, 5000000 ); bith::result_of::fork<AE, f, tuple<double, int> >::type fm3 = bith::fork(ae, f, 2.2, 1000000 ); bith::result_of::fork<AE, f, tuple<double, int> >::type fm4 = bith::fork(ae, f, 2.2, 5000000 ); std::cout << fm2.get() - fm1.get() + fm3.get() - fm4.get() << std::endl; } int main() { bith::launcher ae; doit(ae); } and we can switch from using the launcher or the tp::pool just by changing one line int main() { boost::tp::pool<> ae(boost::tp::poolsize(6)); doit(ae); } The library allows also to fork several functions at the same time template< typename AE, typename F1, ..., typename Fn> typename result_of::fork_all<AE, fusion::tuple<F1,..., F2> >::type fork_all( AE& ae, F1 f1, ..., Fn fn ) { typedef typename result_of::fork_all<AE, fusion::tuple<F1,..., Fn> >::type type; return type(fork(ae,f1),..., fork(ae,fn)); } And use it like: bith::result_of::fork_all<AE, f, g, h>::type handles = bith::fork_all(ae, f, g, h); std::cout << get<1>(res).get() - get<0>(res).get() + get<2>(res).get() << std::endl; The result of the fork_all operation is a Boost.Fusion tuple of asynchronous completion token handles. The user can apply any Boost.Fusion algorithm on this tuple as for example bool b = boost::fusion::none(handles, fct::interruption_requested()); To make common tasks with ACT easier the library provide some ACT related functors in the namespace fct. For the thread interface: * fct::join * fct::join_until * fct::join_for * fct::detach * fct::interrupt * fct::interrupt_requested and for the future interface: * fct::get * fct::wait * fct::wait_until * fct::wait_for * fct::is_ready * fct::has_value * fct::has_exception Here is an example for get: namespace fct { struct get { template<typename ACT> typename ACT::result_type operator()(ACT& t) const { return t.get(); } }; } In addition the library provides some non member functions that are the result of applying these functors to the tuple using a fusion algorithm: * join_all * join_all_until * join_all_for * detach_all * interrupt_all * interrupt_requested_on_all * get_all * get_all_until * get_all_for * wait_all * wait_all_until * wait_all_for * are_all_ready * have_all_value * have_all_exception Next follows how get_all is defined. template <typename Sequence> typename result_of::get_all<Sequence>::type get_all(Sequence& t) { return fusion::transform(t, fct::get()); } The library defines in a systematic way the result_of of a function as a metafunction having the same name as the function on the namespace result_of, as the Boost.Fusion library does. namespace result_of { template <typename Sequence> struct get_all { typedef typename fusion::result_of::transform<Sequence, fct::get>::type type }; } So the user can do the following bith::result_of::fork_all<AE, f, g, h>::type res = bith::fork_all(ae, f, g, h); bith::result_of::get_all<result_of::fork_all<AE, f, g, h>::type values = bith::get_all(handles); or using a typedef typedef bith::result_of::fork_all<AE, f, g, h>::type handles_type; handles_type handles = bith::fork_all(ae, f, g, h); bith::result_of::get_all<handles_type>::type values= bith::get_all(handles); Note that the auto C++0x feature is very useful in these cases. auto res = bith::fork_all(ae, f, g, h); auto values = bith::get_all(handles); Last but not least the library provides also some sugaring functions like wait_for_all that forks and wait for the result. bith::result_of::wait_for_all<AE, f, g, h>::type res = bith::wait_for_all(ae, f, g, h); std::cout << get<1>(res) - get<0>(res) + get<2>(res) << std::endl; and wait_for_any which works with functions that return the same type or are convertible to the same type. bith::result_of::wait_for_any<AE, f, g, h>::type res = bith::wait_for_any(ae, f, g, h); std::cout << "function " << res.first << " finshed first with result=" << res.second << std::endl; Greatings, Vicente Juan Botet Escribá

1 0

Extending Boost.Program_options
by Sami Romdhani 02 Jan '09

02 Jan '09

On the 2007-03-17 Tom Bachmann asked a question on this mailing list on extending boost.program_options with some sort of GUI that would be automatically generated with the list of options of program_options. (see the archive at http://lists.boost.org/Archives/boost/2007/03/118161.php) After a few exchanges with Vladimir Prus, the creator of program_options, the thread was left unfinished. I would like to know if they were any succesful attempts at generating a GUI from program_options. Kind regards, Sami Romdhani. -- http://informatik.unibas.ch/personen/romdhani_sami/

1 0

Re: [boost] [logging] Interest check on logging library.
by Jason Wagner 02 Jan '09

02 Jan '09

> -------Original Message------- > From: Emil Dotchevski <emildotchevski(a)gmail.com> > Subject: Re: [boost] [logging] Interest check on logging library. > Sent: 27 Dec '08 15:25 > > On Fri, Dec 26, 2008 at 9:48 AM, Jason Wagner <jason(a)nialscorva.net> wrote: > > Hello all, > > > > I know there are two proposed logging libraries out there for Boost, > > already, but I had a different itch to scratch on a project. I think I saw > > that Andrey Semashev was going to submit his far more mature version soon, > > but I thought I'd throw my technique out there for an interest check and > > hopefully commentary. This is very much a prototype-- there's a lot of work > > yet to be done but the basic outline and functionality is implemented. > > > > Getting the code > > ---------------- > > http://www.nialscorva.net/boost_logging-0_1.tar.bz2 > > What is the motivation for using boost::mpl in the logging library? I > didn't look too deeply into your code, but wouldn't something like > this work just as well: > > struct logging_debug; > struct logging_release; > > template <class> > struct logging_traits; > > template <> > logging_traits<logging_debug> > { > .... > }; > > In other words, let the user provide an explicit specialization to > configure the logger; once that's done, they just do: > > logger<logging_debug> log; This handles severity, but not necessarily other conditions. The library handles a more general case of this. In the use cases I'm working on, there are multiple independant tags on a record, severity being only one: severity := trace | debug | info | notice | warn | error | fatal // syslog levels, may be missing one build_type := release | debug The logger defines what, if any, conditions of these attributes a record must meet before being logged: logger< mpl::vector< condition::greater_equal<severity::info>, condition::in<build_target::debug> > > log; The logger<logging_debug> log; is equivalent to logger<mpl::vector<condition::greater_equal<severity::debug> > > log; A simple use case would be when you want to put more information into a debug build target than a release build target for the same level of severity: log << severity::info() << "An event that you should be informed of occurred" << build_target::debug() << " debugging information: " << dump_lots_of_info() << end_record(); User defined tag types are extremely easy to make and integrate seamlessly. In the application I'll be using this for, I'll have tags for build_target (client, server, possibly one of several types of server). This could be done via severity levels, but it would be fitting orthogonal concerns into a single enumeration. > My reasoning is that a logging library should be lightweight in terms > of source code; when I need logging, I'd rather not get boost::mpl > too. Understandable. Everything's a matter of tradeoffs. The project I'm working on has a slightly more involved logging use case. One concern I have is how much compile times will be affected by MPL and the templates I'm using and whether the flexibility is worth the cost. > A few more comments: > > In general I don't like using macros or #ifdefs, but one place where I > think they are OK is in a logging library interface, partially because > they make it much lighter, and partially because automatically logging > __FILE__, __LINE__, etc. is desirable IMO. I'm differentiating macros from simple defines. #define LOG_LINE filename(__FILE__) << line(__LINE__) << function(__FUNCTION__) will be in the library in some form in the future. > Finally, I think that all the machinery a typical logging lib uses to > kill logging expressions when they're not needed is an overkill. I've > found that using something as simple as the code below works just > fine: > > namespace logging > { > static bool const warnings=false; > static bool const errors=true; > } > > and then: > > if( logging::warnings ) > log << "Warning"; > > where log simply implements std::ostream. > > You could put the if in a macro but frankly, I personally don't mind > typing it every time; compared to the rest of the junk I have to type > to format a meaningful logging message, the if is not an issue. As a > bonus, you don't have to worry about functions referenced by a logging > expression being executed when logging is not enabled. I'm not a fan of the macros, either. What's really the difference between what you wrote and: LOG_DEBUG(log) << "Warning"; other than the latter being ugly. One of the needs I have is sending output to multiple sinks and reconfiguring filter conditions on the fly (runtime conditions, nt compile time conditions). The if() becomes more complicated and there's visual overhead in having code to change the condition and the potential for typos in non-trivial checks. Hiding that complexity makes the real code more readable and maintainable. That being said, my approach may be overkill for situations of writing to a single file based upon simple variables. I don't think the implementation complexity for the end-user is too high, but it's all about what your needs are. > -- > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > --- Jason Wagner jason(a)nialscorva.net

5 10

AT Commands Sample Needed
by master master 01 Jan '09

01 Jan '09

I need a basic example for sending AT commands to mobile. This will require serial communication on COM port. If any one can send me any example of it.. I want to do this using BOOST. By searching on GOOGLE I got this but this is not compiling. #include <iostream> #include <boost/asio.hpp> #include <boost/asio/serial_port.hpp> #include <boost/thread.hpp> #include <boost/system/error_code.hpp> #include <boost/system/system_error.hpp> #include <boost/bind.hpp> void handler(const boost::system::error_code& error) { std::cout << "read" << std::endl; } int main(int argc, char* argv[]) { using namespace std; using namespace boost; char read_msg_[512]; boost::asio::io_service io; asio::serial_port theport(io,"COM7"); theport.async_read_some(boost::asio::buffer(read_msg_),handler); io.run(); return 0; } Thank You 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/

2 1