May 2016 - Boost-users - lists.preview.boost.org

FindBoost.cmake does not check for include headers
by j.wuttke 11 May '16

11 May '16

As per cmake 3.5.1, FindBoost.cmake does not check for include headers. Therefore it will give false positives - if a Boost project that only consists of a header file is not installed - if only a libboost* is installed, but not the headers from the corresponding *-dev package. I raised this issue long ago on the cmake bug tracker, and recently again on the cmake mailing list, but got no response. Would perhaps somebody from the Boost community volunteer to look into this issue? Or has already looked into it and could tell us what the problem is?

3 4

Fwd: [proto][variant] variant crashes proto expression
by Igor R 11 May '16

11 May '16

The following code is a slightly modified Proto calc2 example. Instead of doubles I use variant<int, double>, and the expression is just _1 = _2. This code triggers assertion in variant/detail/forced_return.hpp, so it looks like some variant instance gets messed up. It happens when the value returned from proto::eval(*this, ctx) is being copied. It can be reproduced both with MSVC and gcc, with Boost 1.60. Is there any workaround for this issue? Thanks. ////////////// #include <iostream> #include <boost/proto/proto_typeof.hpp> #include <boost/proto/core.hpp> #include <boost/proto/context.hpp> #include <boost/variant.hpp> namespace proto = boost::proto; using proto::_; typedef boost::variant<int, double> var_t; template<typename Expr> struct calculator_expression; // Tell proto how to generate expressions in the calculator_domain struct calculator_domain : proto::domain<proto::generator<calculator_expression> > {}; // Will be used to define the placeholders _1 and _2 template<int I> struct placeholder {}; // Define a calculator context, for evaluating arithmetic expressions // (This is as before, in calc1.cpp) struct calculator_context : proto::callable_context< calculator_context const > { // The values bound to the placeholders var_t d[2]; // The result of evaluating arithmetic expressions typedef var_t result_type; explicit calculator_context(const var_t &d1 = var_t(), const var_t &d2 = var_t()) { d[0] = d1; d[1] = d2; } // Handle the evaluation of the placeholder terminals template<int I> result_type operator ()(proto::tag::terminal, placeholder<I>) const { return d[ I - 1 ]; } }; // Wrap all calculator expressions in this type, which defines // operator () to evaluate the expression. template<typename Expr> struct calculator_expression : proto::extends<Expr, calculator_expression<Expr>, calculator_domain> { explicit calculator_expression(Expr const &expr = Expr()) : calculator_expression::proto_extends(expr) {} BOOST_PROTO_EXTENDS_USING_ASSIGN(calculator_expression<Expr>) // Override operator () to evaluate the expression var_t operator ()() const { calculator_context const ctx; return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1) const { calculator_context const ctx(d1); return proto::eval(*this, ctx); } var_t operator ()(const var_t &d1, const var_t &d2) const { calculator_context const ctx(d1, d2); return proto::eval(*this, ctx); } }; // Define some placeholders (notice they're wrapped in calculator_expression<>) calculator_expression<proto::terminal< placeholder< 1 > >::type> const _1; calculator_expression<proto::terminal< placeholder< 2 > >::type> const _2; // Now, our arithmetic expressions are immediately executable function objects: int main() { BOOST_PROTO_AUTO(expr, _1 = _2); var_t a1(1), a2(2.5); expr(a1, a2); return 0; }

1 0

openmpi with boost::log and some late endl
by Peter Vollmer 11 May '16

11 May '16

I'm working on some Linux systems and boost:log. More in detail: After replacing a handmade solution for logging with boost:log and running it with mpi on a single computer I can observe a strange behavior in console. Normally as i understand it, with autoflush turn on, after streaming a message into the logger it follows a flush followed by an endl and flush. At my scenario after streaming messages on different mpi processes, it seem that the system make a thread change right after flushing my message not after the endl flush. The missing automatic endl isn't lost it will be printed directly after or later but it will be printed. One indication that it has to be a thread change of the system is that an increase of the usable mpi processes increases the presents dramatically. For example on 4 core 8 thread system it occurs with 4 mpi processes something around 1 or 2 times, with 8 it occurs more than 20 times. Is there a solution to prevent this? Thanks Peter

1 0

[proto][spirit] parsing into proto expressions
by Igor R 11 May '16

11 May '16

Hi, Long story short: I would like to create proto expressions at run-time using spirit parsers. Would it be possible? More in details: I'd like to parse disassembler output, creating proto expression template for instruction and its operands. Lets assume we define proto expressions that would allow to express the following asm: "lea eax, [ebx + 2 * ecx]" like this: BOOST_PROTO_AUTO(lea_instr, eax = &*(ebx + 2 * ecx)); // registers and immediates are proto terminals Of course, we can't write such an expression in C++ code, because the actual operands get known after the asm string is parsed. So we can express any "lea" in the code (at compile-time) in a more general form, using placeholders: _1 = &_2; Then, when the parser matches "lea", we need to parse and create at run-time the actual operands, i.e. to substitute _1 with eax and _2 with *(ebx + 2 * ecx). I'd appreciate any pointer! Thanks.

2 2

mpfr_float stack allocation
by Daniel Brake 10 May '16

10 May '16

Hi Boost Users, I use Boost.Multiprecision's wrappers for MPFR, particularly the boost::multiprecision::mpfr_float. I've had good success with this library and its types so far, enjoying performance gains because of expression templates, and easy access to mpfr and gmp for floats, ints, and rationals. However, in my complex number type, I am struggling with named real temporaries in arithmetic operators. I am looking for help with multiplication, and I can generalize to all other operations needing a real temporary later. Here's my current code for multiplication, implemented in terms of *=. /** Complex multiplication. uses a single temporary variable 1 temporary, 4 multiplications */ complex& operator*=(const complex & rhs) { mpfr_float re_cache(real_*rhs.real_ - imag_*rhs.imag_); // cache the real part of the result imag_ = real_*rhs.imag_ + imag_*rhs.real_; real_ = re_cache; return *this; } I am using the naive evaluation formula, for better or worse. But the particular method of evaluation doesn't matter to me right now, it's the temporary variable re_cache used to cache the real part is killing me. Profiling using Allinea, gprof, and Callgrind reveals that a significant percentage of time in the program is consumed creating and destroying re_cache, as well as other temporaries scattered throughout my code. In an effort to eliminate heap allocations, I first tried replacing my using mpfr_float = boost::multiprecision::number<boost::multiprecision::mpfr_float_backend<0,boost::multiprecision::allocate_dynamic>, boost::multiprecision::et_off>; with allocate_stack, just for these named temporary variables. However, the documentation <http://www.boost.org/doc/libs/1_60_0/libs/multiprecision/doc/html/boost_mul…> states that allocate_stack only works in fixed precision, so the 0 digits indicating variable precision should cause problems? I expected 0 digits to fail to compile, but compile it does. The conversion from the type with allocate_stack to allocate_dynamic is not provided by the = operator, so I can write re_cache.convert_to<mpfr_float_dynamic>(). But using variable precision with stack allocation appears to cause all sorts of problems. Everything depending on complex multiplication in my program breaks, indicated by massive failures in my test suite. Thus, I currently regard allocate_stack as a non-solution. My question fundamentally regards how to deal with re_cache and the *= operator for complex multiplication. Anyone have ideas on how to get rid of constant heap de/allocation of re_cache without inducing a ton more arithmetic? Using a static for it is not a solution, both because I anticipate multithreading in this application in the future, and the fact that precision will vary though the run, so I'd have to check the precision of re_cache on every evaluation. The C version of the program I am re-implementing used OpenMP for threads, and used a thread-id-indexed global for re_cache. That solution then forces OpenMP onto anyone wanting to use the complex class in multiple threads. Hence, I view this as a non-solution, too. Again, my initial thought was 'heap allocation is the problem here, so I'll use the stack allocated backend'. But variable precision doesn't appear to work with allocate_stack. And statics are no good. Any thoughts? Thanks for your time, Daniel Brake Postdoc University of Notre Dame Applied and Computational Math and Stats

2 1

Re: [Boost-users] [boost] Boost 1.61.0 Release Candidate 2
by Marshall Clow 09 May '16

09 May '16

On Sat, May 7, 2016 at 4:31 AM, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > The second release candidates for the 1.61.0 release are now available at: > > http://boost.cowic.de/rc/boost_1_61_0_rc2.zip > http://boost.cowic.de/rc/boost_1_61_0_rc2.7z > http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.bz2 > http://boost.cowic.de/rc/boost_1_61_0_rc2.tar.gz > > The SHA256 checksums are as follows: > > fa1c34862b7ba8674ed6e064a14667a11830c6252f702d9458451834b74f7815 > boost_1_61_0_rc2.7z > a547bd06c2fd9a71ba1d169d9cf0339da7ebf4753849a8f7d6fdb8feee99b640 > boost_1_61_0_rc2.tar.bz2 > a77c7cc660ec02704c6884fbb20c552d52d60a18f26573c9cee0788bf00ed7e6 > boost_1_61_0_rc2.tar.gz > 02d420e6908016d4ac74dfc712eec7d9616a7fc0da78b0a1b5b937536b2e01e8 > boost_1_61_0_rc2.zip > > The changes relative to RC1 are MSVC fixes for signals2 and graph > libraries. > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. > > I successfully built the .bz2 release with Apple's clang with C++03/11/14/1z. -- Marshall

1 0

Boost ASIO steady_timer and date change
by Sabino Colonna 09 May '16

09 May '16

Hello, I'm using a steady_timer to perform an asynchronous wait in the following manner: boost::asio::io_service io_service; boost::asio::steady_timer my_timer(io_service); void onTimeout(const boost::system::error_code& e) { // Print something } ... my_timer.expires_from_now(std::chrono::seconds(600)); my_timer.async_wait(onTimeout); io_service.run(); If system 'date' does not change, everything is ok. But if I change 'date' by hand while the timer is running, it expires before 600 seconds (more or less after 5 minutes) and 'onTimeout' is called. With synchronous wait, all is ok. According to documentation, steady_timer should not be affected by time change. Which may be the problem? Thanks, Sabino

2 2

Re: [Boost-users] Compiler limitation (MSVS 2015 update 2) or real error using boost::async?
by James Swift 06 May '16

06 May '16

Hi, in case anyone wants to play with the example I provided but doesn't have access to MSVC you can do so online here. http://rextester.com/BAX37541 kind regards, James

2 2

converting to float128 from double
by Cooper, Bridgette R D 04 May '16

04 May '16

Hi, I have a function that takes as an argument a vector of doubles and tries to convert it to a vector of float128. When I accumulate the values in the float128 vector it looks like it does double additions and only casts up at the last step. The initial vector is defined as const std::vector<double> The float128 vector is defined as std::vector<float128> epoint(num) And I try to do the casting (inside a loop) via: epoint.at(i)=(float128(e8.at(i))); If I do the accumulation on the original vector with no casting into a float128, I get the same as accumulating the vector that should be of float128 type. How should I be doing the casting? Thanks,

4 13

Compiler limitation (MSVS 2015 update 2) or real error using boost::async?
by James Swift 04 May '16

04 May '16

Hi, I'm getting an error with the following code only with Visual C++. (VS 2015 update 2. I also tried preview of VS 15 but it's the same) Clang and GCC are OK with this but perhaps VS is just more strict but correct? The error is deep in boost internals and I can't work out which object is move only and/or has it's copy constructor deleted or if it's true at all! Any help greatly appreciated. kind regards, James Swift --------------------------------- #define BOOST_THREAD_PROVIDES_FUTURE #define BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION #define BOOST_THREAD_PROVIDES_EXECUTORS #include <boost/thread/future.hpp> class TestEx { public: void submit(std::function<void()>) { } bool try_executing_one() { return false; } bool closed() { return false; } void close() { } }; int main() { TestEx tex; boost::async( tex, [](){}); return 0; } ----------------------------------- 1>------ Build started: Project: BoostFuture, Configuration: Debug Win32 ------ 1> BoostFuture.cpp 1>c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boost_1_60\boost\thread\future.hpp(3801): error C2280: 'boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::invoker(const boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type> &)': attempting to reference a deleted function 1> c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boost_1_60\boost\thread\detail\invoker.hpp(731): note: compiler has generated 'boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>::invoker' here 1> c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boost_1_60\boost\thread\future.hpp(3800): note: while compiling class template member function 'boost::detail::shared_state_nullary_task<Rp,Cont>::shared_state_nullary_task(const boost::detail::shared_state_nullary_task<Rp,Cont> &)' 1> with 1> [ 1> Rp=Rp 1> ] 1> c:\program files (x86)\microsoft visual studio 14.0\vc\include\xutility(287): note: see reference to function template instantiation 'boost::detail::shared_state_nullary_task<Rp,Cont>::shared_state_nullary_task(const boost::detail::shared_state_nullary_task<Rp,Cont> &)' being compiled 1> with 1> [ 1> Rp=Rp 1> ] 1> c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boost_1_60\boost\thread\future.hpp(3858): note: see reference to class template instantiation 'boost::detail::shared_state_nullary_task<Rp,Cont>' being compiled 1> with 1> [ 1> Rp=Rp 1> ] 1> c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boost_1_60\boost\thread\future.hpp(3873): note: see reference to function template instantiation 'void boost::detail::future_executor_shared_state<Rp>::init<T,Executor>(Executor &,Fp &&)' being compiled 1> with 1> [ 1> Rp=Rp, 1> T=boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>, 1> Executor=TestEx, 1> Fp=boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type> 1> ] 1> c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boost_1_60\boost\thread\future.hpp(3873): note: see reference to function template instantiation 'void boost::detail::future_executor_shared_state<Rp>::init<T,Executor>(Executor &,Fp &&)' being compiled 1> with 1> [ 1> Rp=Rp, 1> T=boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>, 1> Executor=TestEx, 1> Fp=boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type> 1> ] 1> c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boost_1_60\boost\thread\future.hpp(3964): note: see reference to function template instantiation 'boost::future<void> boost::detail::make_future_executor_shared_state<Rp,boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>,Executor>(Executor &,Fp &&)' being compiled 1> with 1> [ 1> Executor=TestEx, 1> Fp=boost::detail::invoker<main::<lambda_4383c995bef90b35d4f40a119c795fc2>,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type> 1> ] 1> c:\users\james\documents\visual studio 2015\projects\boostfuture\boostfuture\boostfuture.cpp(34): note: see reference to function template instantiation 'boost::future<void> boost::async<TestEx,main::<lambda_4383c995bef90b35d4f40a119c795fc2>>(Executor &,F &&)' being compiled 1> with 1> [ 1> Executor=TestEx, 1> F=main::<lambda_4383c995bef90b35d4f40a119c795fc2> 1> ] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

1 0