February 2016 - Boost - lists.preview.boost.org

[Fit] Announcing Fit's formal review (March 2nd)
by paul Fultz 08 Feb '16

08 Feb '16

Dear Boost community, The formal review of the Fit library starts Wednesday, 2nd March and ends on 13th March. Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github: https://github.com/pfultz2/Fit/tree/boost Documentation: http://pfultz2.github.io/Fit/doc/html/ I hope everyone can participate in the review. Thanks, Paul

4 3

How best to implement a bitfield in C++ 14?
by Niall Douglas 07 Feb '16

07 Feb '16

Dear Boost, As part of the AFIO v2 rewrite I've been trying to improve on how AFIO v1 did bitfields by making better use of constexpr and the type system to make usage more natural. I'd appreciate feedback on my efforts. AFIO v1 has an example of usage at https://goo.gl/oVLIjU or https://gist.github.com/ned14/9ef2a9d00da0ffc877b8 and it took the following form: enum class flag : size_t { none=0, delete_on_close=1, disable_safety_fsyncs=2 }; BOOST_AFIO_DECLARE_CLASS_ENUM_AS_BITFIELD(flag) The BOOST_AFIO_DECLARE_CLASS_ENUM_AS_BITFIELD macro declares all the sensible global overloads you'd expect, is type safe and you can use it without surprise except in one single instance: testing for emptiness. The problem is that you cannot declare as a global operator an explicit operator bool nor member functions on enums, so one cannot do if(f) though if(!f) is fine. In AFIO v1, I used if(!!f) and if(!!(f & flag::foo)) everywhere, which is fine if a little abtuse. AFIO v2's current bitfield has an example of usage at https://goo.gl/LsjSGD or https://gist.github.com/ned14/89ee39c6b8eb5254116a and it takes the following form: struct flag : bitwise_flags<flag> { flag() = default; constexpr flag(bitwise_flags<flag> v) noexcept : bitwise_flags<flag>(v) { } static constexpr auto none(){ return bit(0);} static constexpr auto delete_on_close(){ return bit(1); } static constexpr auto disable_safety_fsyncs(){ return bit(2); } }; Here the bitwise_flags<> base class does all the implementation magic, so once again you can use it without surprise except for the obvious clanger - bitfield items are now functions, so instead of the more natural: flag f(flag::disable_safety_fsyncs); flag f2(f&flag::none); f2|=flag::delete_on_close; constexpr flag f3(flag::disable_safety_fsyncs); constexpr flag f4(f3&flag::none); You are stuck with: flag f(flag::disable_safety_fsyncs()); flag f2(f&flag::none()); f2|=flag::delete_on_close(); constexpr flag f3(flag::disable_safety_fsyncs()); constexpr flag f4(f3&flag::none()); I'll admit I started this with the static constexpr flag values being member variables which always works on MSVC and on GCC and clang when the optimiser is running. Unfortunately both GCC and clang appear to be extremely conservative about when a constexpr variable is ODR-used, indeed despite my original design of an unavoidable lvalue-to-rvalue conversion intended to force ODR-used to be off both compilers go ahead and enforce ODR-used anyway which generates undefined reference errors for the storage of the static member variables :( If you'd like to read more about that, and the WG21 DR relating to [basic.def.odr], see https://stackoverflow.com/questions/8016780/undefined-reference-to-sta tic-constexpr-char/28846608#28846608. So, do Boosters think we can actually make a C++ 14 bitfield which: 1. Is typesafe, so not a C bitfield. 2. Is convenient for programmers to declare (i.e. little boilerplate in a specific bitfield declaration). 3. Works as you'd expect a bitfield to work, including bitfield::flag. 4. if(bf) works. 5. Is 100% constexpr and generates zero runtime overhead. My thanks in advance for any advice. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 26

expected/result/etc
by Michael Marcin 07 Feb '16

07 Feb '16

Some months ago there was a lot of discussion regarding Rust style return values for non-exceptional error handling. Did anything ever come of this? Is there a useable library? Apologies if I missed an announcement (I've been away for a bit).

7 31

[gsoc16] ATTN: Project ideas deadline 19th Feb
by Niall Douglas 07 Feb '16

07 Feb '16

Tomorrow 8th February the application period for Google Summer of Code 2016 begins, and yet we have just *one* idea on the ideas page: https://svn.boost.org/trac/boost/wiki/SoC2016 We need *plenty* more if we are to be approved again this year as a Google Summer of Code org, the deadline for which is the 19th February. So if you have some project ideas and think you could mentor a student this summer, *please* consider adding a project idea to the ideas list or stepping forward with a list of Boost libraries or topics you'd be willing to mentor. Our thanks in advance. --- Boost C++ Libraries Google Summer of Code 2016 admin https://svn.boost.org/trac/boost/wiki/SoC2016

1 0

[math] Missing constexpr statement in MPFR bindings
by Claas H. Koehler 05 Feb '16

05 Feb '16

Hi, I encountered a compiler error using gcc-5.0 with the math constants in boost 1.60.0 due to a different exception specification of math::tools::digits(): The prototype defined in math/tools/precision.hpp has a BOOST_NOEXCEPT specifier, while the implementation in math/bindings/mpfr.hpp does not have the respective specification. Adding BOOST_NOEXCEPT in math/bindings/mpfr.hpp solves the problem, i.e. compilation succeeds. I was wondering whether this is a bug or whether the error can be circumvented in another way. Regards Claas

2 1

Is there interest in Computable Calculus?
by Alexander Lauser 05 Feb '16

05 Feb '16

Hi, An arithmetic operation produces a new function using the functions in the operands and some simple expression manipulations. if I gather it right, then what you propose is basically a Computer Algebra System (i.e., a system for manipulating reals by symbolic expressions). What specifically would the goal of the library be? Best, Alex

2 5

updated version of safe integer library
by Robert Ramey 05 Feb '16

05 Feb '16

I've updated my safe integer library. Pointers to the most recent documentation and code can be found at www.blincubator.com . Or one can use documentation http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/… repository: https://github.com/robertramey/safe_numerics I've resolved added more tests. added more examples and explanation of them added facilities to enforce a guarantee of zero runtime penalty added new section to the documentation of the above added more documentation regarding the library implementation. and other stuff. There is still a little more to do. But there is nothing that I know about that would prevent users from using this library right now to implement guaranteed correct integer arithmetic in their applications. Of course I'm interested any feedback and/or observations anyone want's to offer. Robert Ramey

5 13

[iterator] Boost zip iterator
by Claas H. Koehler 05 Feb '16

05 Feb '16

First of all thanks for implementing the support of std::pair with the zip iterator in boost 1.60. While testing the feature, I noticed that it is necessary to add the following include #include <boost/fusion/adapted/std_pair.hpp> before code using the zip iterator with std::pair. Just wondering if this was intentional behaviour or if the include should happen directly in zip_iterator.hpp. Anyway, the feature works great and is a real improvement for our projects. Regards Claas

1 0

Transferring the boost-qvm github repository to Boost
by Emil Dotchevski 03 Feb '16

03 Feb '16

Hello, Ron Garcia, one of the Boost Review Wizards, has directed me to ask the mailing list about the exact procedure for transferring the boost-qvm github repo to Boost. I believe I need to have some kind of permissions to be able to use the built-in github repo transferring mechanism. Thanks, Emil

2 1

[Math] Statistical Distributions parent distribution class
by Clancy Emanuel 01 Feb '16

01 Feb '16

In the Statistical Distributions section of Boost.Math there is a future directions link that talks about an "any_distribution" class. Is this planned for a future release? Is anyone working on this? I came across a need for this when writing a lambda to find the pdf of a certain value of a random variable. It would be helpful for iterating over a vector of random variables whose distributions are not the same.

2 1