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

[test] Not using Boost.Test for an official Boost library
by Vinícius dos Santos Oliveira 22 Mar '16

22 Mar '16

Hi list, I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost. After facing an issue trying to enable compiler santizers on my tests[1] for long enough, I'd like to use a different test library. According to a survey done by Niall concerning new libs[2], everybody avoids Boost.Test, favouring assert/static_assert. I've been interested in using Catch[3], which is header-only and can be embedded, posing no problem to users (it'd be transparent). I've seen Boost.AFIO (which is not an official Boost library) already uses it. I've seen lightweight_test is also used within Boost[4]. If Boost.Test ever fix its integration problem with compiler sanitizers[1], I'd have no problem migrating everything back again to Boost.Test. However, it's more important for me to have this issue solved now so I can jump to the next task (valgrind and fuzz testing). I've also seen that some header-only libraries use a different build system for the test target[5] and using a header-only test library would be a lesser demand that should be okay. [1] https://svn.boost.org/trac/boost/ticket/11425 [2] https://raw.githubusercontent.com/boostcon/cppnow_presentations_2015/master… [3] https://github.com/philsquared/Catch [4] http://www.boost.org/doc/libs/1_60_0/libs/core/doc/html/core/lightweight_te… [5] https://github.com/boostorg/hana/blob/63c5f87dfdadd07e496cefefc63c3ea9968d3… -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

6 5

Boost 1.61.0 Beta 1 Release Candidate 1
by Vladimir Prus 22 Mar '16

22 Mar '16

Release candidates for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z 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. These packages were generated by the CI system that Rene has put together, and one user-visible change is that the directory inside archive is named after git commit hash. This will be changed for the final release. Otherwise, these were smoke-tested on Windows and Linux, and should be functionally identical to usual packages. The SHA1 checksums are as follows: b8314cff39908e6d6221bdad01ce1f1468546419 boost_1_61_0_b1_rc1.zip cd916da1aa5ed812e538975171069506ecc4560c boost_1_61_0_b1_rc1.tar.bz2 ca18da298d739ef70145b29e3bd2c8d903067075 boost_1_61_0_b1_rc1.tar.gz 2fb4b8cf9112f59aa1c4b61f2ea0c66cbbe3ffd0 boost_1_61_0_b1_rc1.7z The SHA256 checksums are as follows: 3668b868d3f883327e2ff1324e09899cbb033087147d4dd268424a7729791f94 boost_1_61_0_b1_rc1.zip e07784e9770193ff1e68cfe05c6fd08ca05913afedaedf1aca33f6da30d49b17 boost_1_61_0_b1_rc1.tar.bz2 2344369b6859ed151589286d05b38764a902884c10a4dac9c67b133c6c046130 boost_1_61_0_b1_rc1.tar.gz 9ab80608c9ec70ec7afee25f2213f803ed3d15a71ade2c6ae184c48f33fd9d29 boost_1_61_0_b1_rc1.7z Thanks! -- The release managers

10 18

[Fit] formal review starts today
by Vicente J. Botet Escriba 21 Mar '16

21 Mar '16

Dear Boost community, sorry for the late anounce The formal review of Paul Fultz II's Fit library starts today, 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/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here:http://www.boost.org/community/reviews.html We await your feedback! Best regards, Vicente J. Botet Escriba

10 64

[Fit] formal review is over
by Vicente J. Botet Escriba 21 Mar '16

21 Mar '16

Hi, The review of the Fit library finished yesterday 20 March. Thanks to all the people who participated in the review, as a reviewer or commenting the threads. I hope to announce the result soon ;-) Best, Vicente P.S. Of course you/we can continue with the discussion and add issues in github that would help to improve the library. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/

1 0

[fit] Mini Review (consider 1/2 or 1/4 weight)
by Artyom Beilis 21 Mar '16

21 Mar '16

Disclaimer: please consider my review as partial if at all because of the way I did it (see notes below) > - Whether you believe the library should be accepted into Boost No, I don't think so. I don't feel that library adds any real value to boost: being useful or in other words significantly simplifying rather straight forward tasks can't be done However I understand that there are some cases with template meta-programming that can make library useful shown there: http://article.gmane.org/gmane.comp.lib.boost.devel/265453 So I do think it another major review after significant redesign can be done. > - Your name Artyom Beilis > - Your knowledge of the problem domain. I worked a lot with lambda expressions and various callbacks also mostly in dynamic manner rather implementing functional programming. > - What is your evaluation of the library's: > * Design I did very brief analysis of design. What concerns me is wide use of static objects and declaration of "static functions". There is significant difference between static struct foo_class { void operator()() const;... } foo; and inline void foo() { } Of course two issues: 1. Inline functions are weak symbols and don't violate ODR 2. Static variables in C++ do violate ODR (btw in C they do not) so basically you COPY every instance of the functions across compilation unit. If you define some static function that does something by macro I'd rather expect to see stuff like inline void foo(...) { static foo_instance ... f = ...; f(...) } I don't know if it is implementable but it makes more scene or at least justify use of macro. On the other hand I don't see (with exception of some corner cases) why this is better than BOOST_FIT_STATIC_FUNCTION(foo) = fit:compose(bar1,bar2) // * calls bar1(bar2(...)) inline void foo(...) { bar1(bar2(...)) } or inlined auto foo = fit:compose(bar1,bar2); Is better than auto foo = [](...) { bar1(bar2(...) ) }; I understand (after getting this reply http://article.gmane.org/gmane.comp.lib.boost.devel/265453) That there are some meta-programming cases that the library is really helpful. But this isn't something I see in library documentation or it isn't the major library purpose. And for trivial cases I think direct approach is better as it is just clearer and easier to understand for an average code maintainer. > * Implementation Reviewed barely... no comment > * Documentation This is another major issue it does not clear what library does and how it is useful. This alone would make a condition on the acceptance. > * Tests Didn't reviewed > * Usefulness It is probably the major questions that the library need to ask. What is the purpose of the library and what problem it solves. I didn't find a complete answer to this question. > - Did you attempt to use the library? If so: No > - How much effort did you put into your evaluation of the review? Several hours - mostly reading docs and code. I can't say I reviewed most of the code or most of the docs. I stopped before as I couldn't find the satisfying answers regarding what library does. I understand that if somebody would submit the library regarding astrophysics or bio-modeling I'd had hard time to understand what library does. However regarding FIT I don't think it is the case. So if you (review manager/library designer) feel that I attempted to review a library in a field I don't get - feel free to ignore my review. Artyom Beilis

7 8

[release] New libraries documentation + release notes
by Daniel James 20 Mar '16

20 Mar '16

Hi, I'm starting to compile the release notes, so please add the info for your library. Easy way to do so is to click the pencil icon at the top right of the code at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_61_0.q… Or you can just email me if you don't like quickbook. Also, the documentation for the new libraries in this release is now building okay and I've added links to the release notes, so please can the relevant people take a look: http://www.boost.org/users/history/version_1_61_0.html thanks, Daniel

3 4

[1.61] Two weeks remaining for new libraries and breaking changes
by Vladimir Prus 19 Mar '16

19 Mar '16

I wanted to remind that the master branch is closing for new libraries and breaking changes on Feb 24, about two weeks from now. We'll be closed for major changes on March 2. That's not a lot of time, please make sure any big work is completed. Thanks, -- Vladimir Prus http://vladimirprus.com

10 38

[Spirit X3] move_to
by Mikhail Strelnikov 18 Mar '16

18 Mar '16

Hi, I'm using Boost 1.60 with Spirit X3 from develop branch (because it has this fix <http://boost.2283326.n4.nabble.com/Single-element-attributes-in-X3-quot-sti…> ). If I change the rule from this: auto a2 = rule<class i2, ast::a2>{} = a1 >> a2_v2; to this: auto a2 = rule<class i2, ast::a2>{} = a1 >> '(' >> a2_v2 >> ')'; it stops compiling (both gcc and clang) with error "no matching function for call to 'move_to'". Here is full source code: #include <boost/spirit/home/x3.hpp> #include <boost/spirit/home/x3/support/ast/variant.hpp> #include <boost/fusion/include/define_struct_inline.hpp> #include <string> #include <vector> namespace ast { BOOST_FUSION_DEFINE_STRUCT_INLINE ( a1, (std::string, v) ) BOOST_FUSION_DEFINE_STRUCT_INLINE ( a2, (a1, v1) (std::vector<double>, v2) ) BOOST_FUSION_DEFINE_STRUCT_INLINE ( a3, (std::vector<a2>, v1) ) } using namespace boost::spirit::x3; auto a0 = rule<class i0, std::string>{} = lexeme[+alpha]; auto a1 = rule<class i1, ast::a1>{} = a0; auto a2_v2 = rule<class a2_v2, std::vector<double>>{} = -(double_ % ','); auto a2 = rule<class i2, ast::a2>{} = a1 >> '(' >> a2_v2 >> ')'; //auto a2 = rule<class i2, ast::a2>{} = a1 >> a2_v2; auto a3_v1 = rule<class a3_v1, std::vector<ast::a2>>{} = *(a2 >> ';'); auto a3 = rule<class i3, ast::a3>{} = a3_v1; using data = ast::a3; int main() { std::string script = ""; auto begin = script.begin(); auto end = script.end(); data v; bool ok = (boost::spirit::x3::phrase_parse(begin, end, a3, space, v) && begin == end); } Here is how it is compiled: #!/bin/bash wget --no-clobber http://netcologne.dl.sourceforge.net/project/boost/boost/1.60.0/boost_1_60_… tar -zxvf boost_1_60_0.tar.gz wget --no-clobber https://github.com/boostorg/spirit/archive/develop.zip unzip develop.zip mv ./boost_1_60_0/boost/spirit ./boost_1_60_0/boost/spirit_old g++ -std=c++14 test.cpp -I./spirit-develop/include/ -I./boost_1_60_0/ -o test

1 0

[Root Pointer] Benchmark
by Phil Bouchard 17 Mar '16

17 Mar '16

So I renamed block_ptr<> to root_ptr<> and the code is accessible from here: https://github.com/philippeb8/root_ptr I am sorry but I made a mistake in the benchmark again. root_ptr<> wasn't using the fast allocator. Now it does and the new benchmark is: unique_ptr (new): 42.3736 unique_ptr (make_unique): 59.6104 shared_ptr (new): 69.9175 shared_ptr (make_shared): 46.9994 shared_ptr (allocate_shared_noinit): 31.0648 root_ptr (new): 30.5549 Regards, -Phil

5 36

[ann][offtopic] GSoC with the STE||AR-Group
by Thomas Heller 17 Mar '16

17 Mar '16

Hi list, We are very sad that Boost didn't make it into GSoC this year. However, for students with enthusiasm for C++, Parallelism and Concurrency and looking for an interesting project for this summer, there are other opportunities. The STE||AR-Group (https://summerofcode.withgoogle.com/organizations/5183170693562368/) is looking for prospective students, we have a large variety of projects surrounding the HPX Parallel Runtime System (one of the reference implementations of the upcoming additions to the C++17 standard for parallelism and concurrency). You can find our project ideas list here: https://github.com/STEllAR-GROUP/hpx/wiki/GSoC-2016-Project-Ideas In addition, if you have a project idea you'd like to mentor that would fit into the scope of our organisation, we would be more than happy to welcome you! We are looking forward to your responses at hpx-users(a)stellar.cct.lsu.edu or on our IRC channel #ste||ar on Freenode! Best regards, Thomas -- Thomas Heller Friedrich-Alexander-Universität Erlangen-Nürnberg Department Informatik - Lehrstuhl Rechnerarchitektur Martensstr. 3 91058 Erlangen Tel.: 09131/85-27018 Fax: 09131/85-27912 Email: thomas.heller(a)cs.fau.de

1 0