- Boost - lists.boost.org

[test] Broken with VC7.1?
by John Maddock 07 Jan '09

07 Jan '09

All the math lib tests are now failing with VC7.1 due to an unresolved external from Boost.Test: http://tinyurl.com/9s9s8e Any fixes? Cheers, John.

2 2

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