- Boost - lists.boost.org

For Boost PP: IF_NONEMPTY(), IS_NONEMPTY
by Daniel Santos 11 May '12

11 May '12

I came up with some macros the other day trying to solve a kernel problem and I haven't seen them anywhere else and if I found one, I sure would have stolen it. :) I used this to have a single function-like macro service different numbers of parameters, essentially adding "optional parameter" support so I didn't have to have different version of the macro. IF_NONEMPTY(test, result) expands to result if test is non-empty, empty otherwise. IS_NONEMPTY(arg) expands to 0 if arg is empty, 0x1 if it isn't. OPT_OFFSETOF(type, member) isn't very useful in C++, but it is an example of how the above can be used. It expands to a compiler-time constant that is the offset of the member in the struct or union type, unless member isn't specified, in which case it's zero. #define __JUNK junk, #define _if_nonempty(arg1_or_junk, result) __if_nonempty(arg1_or_junk, result) #define __if_nonempty(__ignored, result, ...) result #define CONCAT_TOKEN(a, b) _concat_token(a, b) #define _concat_token(a, b) a ## b #define IF_NONEMPTY(test, result) _if_nonempty(__JUNK##test, result) #define IS_NONEMPTY(arg) CONCAT_TOKEN(0, IF_NONEMPTY(arg, x1)) #define OPT_OFFSETOF(type, m) ((size_t) &((*((type *)0)) IF_NONEMPTY(m,.)m))

3 3

[reference_wrapper] add operator()(Args...) to reference_wrapper
by Philipp Moeller 10 May '12

10 May '12

Given that Boost now has perfect forwarding emulation through Boost.Move and a better result_of, would it be possible to enable reference_wrapper to forward the function call operator? The current behavior is somewhat surprising and makes a few of the most promising applications of reference_wrapper (reference wrap polymorphic boost::function objects) impossible with code that is no prepared to work with reference_wrapper. It would also be more consistent with reference_wrapper of the stdlib. I can file a corresponding bug report and add a patch, if there is interest. Cheers, Philipp Moeller

2 5

[multi_array] Updated patches
by Bill Buklis 10 May '12

10 May '12

For the multi_array library, there is an updated version of the library in the trunk plus a few tickets that have proposed patches. These are updates for some fairly important issues. I'd absolutely love it if these patches could be incorporated into the next boost release, whenever that may be. I realize that the official maintainer, Garcia, is understandably very busy, so could one of the powers that be please review these patches for correctness and update the official libraries as needed? Here are the tickets that already have proposed fixes: ticket:4874 <https://svn.boost.org/trac/boost/ticket/4874> - multi_array compile errors using Visual C++ 2010 in debug mode ticket:6554 <https://svn.boost.org/trac/boost/ticket/6554> - Compiler error dereferencing multi_array value via an iterator ticket:6811 <https://svn.boost.org/trac/boost/ticket/6811> - Default argument of type multi_array fails under MSVC 2010 SP1 Thanks, -- Bill

1 0

[preprocessor] include speed question
by lcaminiti 10 May '12

10 May '12

Hello all, I have a general question about what's the best way to include files that results in faster compilation time. In my example, I have *a lot* of files that use different parts of Boost.Preprocessor. Each header includes the specific Boost.Preprocessor headers that it needs. As a results the same Boost.Preprocessor header and #included many times (50+?) even if the including has no effect after the first inclusion. Furthermore, at the end essentially all Boost.Preprocessor header get included. This way is more module in that each single file includes all the headers that it needs. But, does that slow down compilation? Would it be faster to just #include <boost/preprocessor.hpp> just once into a front-end header that then includes all my single header files? (Maybe with modern compilers and file-systems this makes no difference?) Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-include-speed-questio… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Scoped enum emulation
by Anthony Williams 10 May '12

10 May '12

Hi, On trunk there are currently two scoped enum emulation headers. One is the one that Beman wrote, in boost/detail/scoped_enum_emulation.hpp and the other is the one that Vicente has developed for the new version of Boost.Thread, in boost/thread/detail/scoped_enum.hpp It seems to me that it is a shame to have two implementations of the same thing in boost. Since Vicente's version provides additional facilities, I would therefore like to merge Vicente's code into the boost/detail header. We could retain the simple macros from Beman's header as wrappers for the more complex macros that Vicente has written. What do you think? Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++11 thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 2

[mpl] cross product and gcc specific compiler error
by Josh Quigley 10 May '12

10 May '12

Hi, A question from the grossly uninformed: I grabbed an mpl cross product implementation (product_view) of this mailing list. It works fine in MSVC but fails in gcc: typedef boost::mpl::vector<float, double, long double> DecimalTypes; typedef boost::mpl::vector<int, unsigned int, long, unsigned long, long long, unsigned long long> IntegralTypes; typedef product_view<boost::mpl::vector<DecimalTypes, IntegralTypes> > EachDecimalWithEachIntegralT; BOOST_AUTO_TEST_CASE_TEMPLATE(MyTest, DecimalIntegralT, EachDecimalWithEachIntegralT) { { typename DecimalIntegralT::item1 r(1234567); // Fails on gcc: no type named ‘item0’ in ‘struct boost::mpl::v_item<long long unsigned int, boost::mpl::v_item<ext::decimal::decimal128, boost::mpl::vector0<mpl_::na>, 0>, 0> typename DecimalIntegralT::item0 d(r); BOOST_CHECK_EQUAL(static_cast<long long>(d), r); } } A complete listing is below. The thing that has me really stumped is the type exsits in MSVC, so I'm at a bit of loss of how to proceed debugging. // // LISTING // #include <boost/mpl/vector.hpp> #include <boost/mpl/if.hpp> #include <boost/mpl/at.hpp> #include <boost/mpl/copy.hpp> #include <boost/mpl/transform.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/function.hpp> #include <boost/mpl/vector.hpp> #include <boost/mpl/list.hpp> #include <boost/mpl/joint_view.hpp> #include <boost/test/unit_test.hpp> namespace detail { using boost::mpl::at_c; using boost::mpl::at; using boost::mpl::vector3; using boost::mpl::true_; using boost::mpl::false_; using boost::mpl::if_; using boost::mpl::next; using boost::mpl::bool_; using boost::mpl::front_inserter; using boost::mpl::clear; using boost::mpl::forward_iterator_tag; using boost::mpl::reverse_copy; using boost::mpl::transform1; using boost::mpl::deref; using boost::mpl::_1; using boost::mpl::_2; using boost::mpl::int_; using boost::mpl::fold; using boost::mpl::or_; using boost::mpl::nested_begin_end_tag; template<typename S, typename O> struct state_with_overflow { typedef S state; typedef O overflow; }; template<typename I3S> struct i3s_increment_inserter { template<typename I3, typename O> struct i3_ { typedef I3 i3; typedef O overflow; }; template<typename I3> struct incr_ { typedef typename next< typename at_c< I3, 1 >::type >::type next_; typedef bool_< boost::is_same< next_, typename at_c<I3,2>::type >::value > overflow_; typedef i3_< vector3< typename at_c<I3,0>::type, typename if_< overflow_, typename at_c<I3,0>::type, next_ >::type, typename at_c<I3,2>::type >, overflow_ > type; }; typedef front_inserter< typename clear<I3S>::type > base_; typedef state_with_overflow< typename base_::state, true_ > state; struct operation { template<typename S, typename I3> struct apply { typedef typename if_< typename S::overflow, typename incr_<I3>::type, i3_<I3,false_> >::type next_; typedef state_with_overflow< typename base_::operation::template apply< typename S::state, typename next_::i3 >::type, typename next_::overflow > type; }; }; }; template< typename SWO > struct product_iterator { private: typedef typename SWO::state I3S; public: typedef forward_iterator_tag category; typedef typename transform1< I3S, deref< at< _1, int_<1> > > >::type type; typedef product_iterator< typename reverse_copy< I3S, i3s_increment_inserter<I3S> >::type > next; }; template<typename S> struct product_view { private: typedef typename transform1< S, vector3< boost::mpl::begin<_1>, boost::mpl::begin<_1>, boost::mpl::end<_1> > >::type begin_impl; typedef typename fold< S, false_, or_< _1, boost::is_same< boost::mpl::begin<_2>, boost::mpl::end<_2> > // empty<_2> refuses to compile on MSVC 7.1 > >::type empty_result; public: typedef nested_begin_end_tag tag; typedef product_iterator< state_with_overflow< begin_impl, empty_result > > begin; typedef product_iterator< state_with_overflow< begin_impl, true_ > > end; }; } using detail::product_view; // typedef boost::mpl::vector<decimal32, decimal64, decimal128> DecimalTypes; // Original typedef boost::mpl::vector<float, double, long double> DecimalTypes; // for demonstration typedef boost::mpl::vector<int, unsigned int, long, unsigned long, long long, unsigned long long> IntegralTypes; typedef product_view<boost::mpl::vector<DecimalTypes, IntegralTypes> > EachDecimalWithEachIntegralT; BOOST_AUTO_TEST_CASE_TEMPLATE(MyTest, DecimalIntegralT, EachDecimalWithEachIntegralT) { { typename DecimalIntegralT::item1 r(1234567); // Fails on gcc: no type named ‘item0’ in ‘struct boost::mpl::v_item<long long unsigned int, boost::mpl::v_item<ext::decimal::decimal128, boost::mpl::vector0<mpl_::na>, 0>, 0> typename DecimalIntegralT::item0 d(r); BOOST_CHECK_EQUAL(static_cast<long long>(d), r); } }

1 0

[coroutine]
by Christopher Kormanyos 10 May '12

10 May '12

Hello, I am checking out the fascinating work with Boost.Coroutine. Excellent! This is definitely paving the way for C++ threads. I have been looking for this kind of thing for quite some time now. I am mostly interested in adaptability, as I386 and the lot are mostly done. It's always the same game with the cooperative context switching. Time-after-time, you identify the clobbered registers after a cooperative yield, save them in a context structure and restore them after the yield. Then you deal with the stacks. OK, fine. But how can you approach the dream of generic context switching? So you know, here I am. I would want Boost.Context for numerous GCC targets: Atmel AVR, Renesas V850, Renesas RL78, Cortex-M3/4. And the list goes on, as I use numerous embedded processors. The compiler's calling convention is poorly documented at best. And various compiler vendors may or may not coordinate the calling convention among each other. Can the documentation of Boost.Coroutine aid in adaptation in any way? Or is this simply beyond the present scope of the proposed Boost.Coroutine? * Is there any documentation regarding the context switch? * Are you specifically targeting preemptive yields? * If so, is the compiler's calling convention taken into account? * Can the remarkable Boost.Coroutine be adapted to other CPUs? * How? * Is Coroutine meant to be compatible with std::this_thread::yield(), etc? * Can the user select the stack sizes? * How? Thank you. And keep up the great work! Best regards, Chris.

3 6

[coroutine] request for review manager
by Oliver Kowalke 10 May '12

10 May '12

Hi, I want to ask who wants to be the review manager for boost.coroutine? The documentation is updated and available at: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/index.html best regards, Oliver

2 4

[serialization] portable_binary_archive using shared lib
by Renato Tegon Forti 09 May '12

09 May '12

Hi, I want use portable_binary_archive, but using shared link on Windows! Have any way? Thanks

1 0

[exception] patches for a few testing-related issues
by David Deakins 09 May '12

09 May '12

Hi Emil, I have opened two Trac tickets (6877 and 6878) related to what I believe is a bug in exception_ptr_test.cpp and also for a minor change to the testing jamfile that will allow some of the thread-dependent tests to run on platforms that do not have automatic thread-specific-storage cleanup implemented (WinCE falls in this category). Are you ok with me applying these patches? Thanks, -Dave

2 1