April 2017 - Boost - lists.preview.boost.org

[metal] Formal Review - Request for Endorsement
by Bruno Dutra 16 Apr '17

16 Apr '17

Dear Community, I'd like to formalize what has been known to many for some time now and request the formal review of Metal, a modern C++14 library designed to make template metaprogramming intuitive and effectively replace Boost.MPL. Klemens Morgenstern has kindly offered to manage the review process. The library is available on github at https://github.com/brunocodutra/metal The full documentation is available online at http://brunocodutra.github.io/metal/ Up to date benchmarks are uploaded daily to metaben.ch Great effort has been put into making Metal as portable to different compilers as possible. Currently, the following compilers are tested in continuous integration using Travis and Appveyor: * GCC 4.7 and above * Clang 3.4 and above * Xcode 6.4 and above * Visual Studio 14 (2015) and above * MinGW 5 and above Complying with the new Boost policy, I'd like to kindly request those interested in seeing Metal in boost to take a look at it and endorse this request for formal review. Regards, Bruno

5 6

[config] What to call macros to indicate deprecated/removed components
by John Maddock 16 Apr '17

16 Apr '17

We now have several former C++ features which are removed in C++17: auto_ptr random_shuffle binders unary/binary_function And we're getting requests for configuration macros for these, the question is what to call them? We could stick with the (easy to implement) existing naming and just use: BOOST_NO_<FEATURE> or we could use: BOOST_<STD>_REMOVED_<FEATURE> which is a bit more work as all the scripts that rely on the BOOST_NO/BOOST_HAS convention need updating. Any other suggestions/preferences? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

6 6

[typeof][scope_exit] VS2017 and option /permissive-
by Daniela Engert 16 Apr '17

16 Apr '17

Hello, late last year, VS2017RC gained a compiler option /permissive- which disables some non-conforming behaviour. Source code that was accepted by previous versions of msvc, and still is accepted by msvc 14.1 without this compiler option, is rejected and flagged as an error if /permissive- is engaged. For more on this see https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/. While checking our company's codebase for possible problems related to that I noticed compile errors in Boost.Log and traced the problem back to Boost.Typeof and in particular "libs\typeof\include\boost\typeof\msvc\typeof_impl.hpp". Therein is code emulating the missing __typeof__ keyword by taking advantage of a silent msvc compiler 'bug' as a 'feature'. Parts of this code are duplicated in a msvc-specific workaround in Boost.Scope_Exit. This compiler bug is no longer silent with /permissive- in place but rather a hard error. As it turns out, I'm not the first to be bitten by this: ticket #12900 tells the same story. Many other Boost libraries use Boost.Typeof directly or indirectly and therefore suffer from the same problem (like Boost.Log in my particular case). I've implemented a possible solution and created two pull-requests: - https://github.com/boostorg/typeof/pull/7 - https://github.com/boostorg/scope_exit/pull/3 The patches only affect msvc 14.1. With these patches applied, the test results of the full Boost testsuite are the same as without these patches. I don't know enough about __typeof__ to decide if my emulation is compatible in every aspect, but at least it's good enough to pass the testsuite. There are two other compile failures introduced with /permissive- in place which are compiler bugs which need to be addressed by Microsoft's compiler team. Fortunately these are very specific to just two libraries, Boost.Spirit.Repository (one test case) and Boost.Geometry (two test cases caused by one single function). -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

2 8

Boost licensing information
by Fabrizio Riente 15 Apr '17

15 Apr '17

Dear Boost Members, I'm Fabrizio Riente and I'm a researcher from the Politecnico di Torino in Italy. I'm using some part of boost libraries in our application. In particular we are using boost spirit, odeint and serialization. In the next future, we would like to release this tool for free for research purposes. I read that at the moment boost is released under Boost license. I was wandering if under this license it is possible to distribute the application for free to other universities and interested people without sharing the source code. Thanks in advance for your time. Best regards. Fabrizio Riente -- Fabrizio Riente, Postdoctoral Research Associate Politecnico di Torino, Dept. of Electronics and Telecommunications C.so Duca degli Abruzzi 24, I-10129, Torino, Italy Phone: +39 011 090 4241, Email: fabrizio.riente(a)polito.it

15 43

Header Inclusion practices
by Robert Ramey 15 Apr '17

15 Apr '17

As long as I can remember, it's been my practice to write program code to minimize dependencies on the environment in which it is built. By environment I mean things external to the code itself like environmental and command line variables, directory context etc. As part of this I use rules for header file inclusion: a) use #include "header.hpp" for files in the same directory as the current source file. b) use #include "other directory/header.hpp" for files which are known to be in a specific place relative to the current file. This shows up in things like: #include "../include/header.hpp" for tests and examples. c) use #include <boost/serialization/xml_archive.hpp> for files which are found by looking in directories listed in "-I" switches and environmental variables (INCLUDE). I generally try not to depend upon any environmental variables as I always forget to set them or even how to set them. Come to think about it. I don't know how my build system finds the boost libraries. I presume it's through some IDE/Bjam/CMake setting which I can never remember. d) use #include <iostream> for standard library components. Presumably these are routed to some directory relative to the compiler. So some of my source files look like: // interval.hpp header for safe numerics library #include <limits> #include <cassert> #include <type_traits> #include <array> #include <initializer_list> #include <boost/logic/tribool.hpp> #include <boost/core/demangle.hpp> #include "utility.hpp" // log #include "checked_result.hpp" #include "checked.hpp" and // example using he safe numerics library #include <iostream> #include <limits> #include <boost/integer.hpp> #include "../include/cpp.hpp" #include "../include/exception.hpp" #include "../include/safe_integer.hpp" #include "../include/safe_range.hpp" This has raised consternation in some quarters - but I don't see anything wrong with it. It basically means that only the <boost libraries are depended on the whole b2 business. I didn't want the incubator version of the the safe numeric library to depend on the library having been accepted into boost have have b2 run. Also I don't like adding the library to boost - and having to change all the headers. What if someone want's to run the tests/examples outside of the boost tree. As far as I know this question has never been asked before and I'm curious to know what others might have to say about this. Robert Ramey

10 21

gil: extension/numeric missing in tarball(s)
by Tim Blechmann 14 Apr '17

14 Apr '17

hi all, the complete folder with the gil numeric extensions is not included in the tarball ... is this a bug or a feature? https://github.com/boostorg/gil/tree/develop/include/boost/gil/extension/nu… thnx, tim

4 6

[release 1.64] - BOOST_NO_CXX17_STD_APPLY missing in documentation
by Oliver Kowalke 14 Apr '17

14 Apr '17

I checkted the documentation of boost-1.64 beta2 and it seams that the documentation lost the description of BOOST_NO_CXX17_STD_APPLY. May I provide a patch that gets merged into the 1.64 release? Oliver

3 3

[config] defect macro for chrono literals
by Oliver Kowalke 14 Apr '17

14 Apr '17

boost.config defines BOOST_NO_CXX11_USER_DEFINED_LITERALS but I believe this defect macro could not be used for detecting chrono literals support. Should the new BOOST_NO_CXX14_CHRONO_LITERALS depend on the compiler or stdlib version? AFAIK chrono literals are available since gcc-4.9.3 (clang?, intel?, msvc?). Oliver

2 2

[CallableTraits] Closing the review period
by Louis Dionne 13 Apr '17

13 Apr '17

Dear Boost, The review period for CallableTraits is about to conclude (in about one hour, PST). So far, I have counted 5 formal reviews, alongside with other valuable feedback. All 5 formal reviews recommend acceptance (along with improvement suggestions, but I read none of them as being conditional). I will weight the different comments received through formal and informal reviews and come back with a decision regarding CallableTrait's inclusion in Boost by the end of next week. Thanks for everyone's involvement in the review. Louis P.S.: If you have a late review, submit it ASAP and I will consider it!

1 0

[release] 1.64.0 closed for all changes.
by Rene Rivera 13 Apr '17

13 Apr '17

The Boost 1.64.0 master branch is now closed for all changes. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0