- Boost - lists.preview.boost.org

[ranges] Please merge the long standing pull request
by Antony Polukhin 18 Apr '17

18 Apr '17

Hello, There's a year old pull request https://github.com/boostorg/range/pull/44 Please merge it to the develop branch. The pull request is a blocker for improving Boost.Algorithm (https://github.com/boostorg/algorithm/pull/35) https://github.com/boostorg/range/pull/44 changes were adopted into C++17 standard library.So the change is not innovative. -- Best regards, Antony Polukhin

2 2

Serialization support for colony container
by Brian Wood 17 Apr '17

17 Apr '17

Shalom It's looking like Matthew Bentley's colony container -- http://plflib.org -- is going to pass over Boost on it's way to the standard. I've added serialization support for this container to the C++ Middleware Writer and added some code that tests that support to my repo -- https://bitbucket.org/webenezer/onwards . I enjoyed Jon Kalb's CppChat show where he talked to Matthew about this container -- http://www.slashslash.info/cppchat/ https://www.youtube.com/watch?v=SFAJ238rBNw -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

Guinea pigs for testing GSoC submission ranking
by Niall Douglas 16 Apr '17

16 Apr '17

Google have removed the ability for the community to rank proposals plus they force proposals to be sent to us in the highly unuseful PDF format. I've come up with a stopgap solution, and need guinea pigs for testing it. If you're game, please send me your google login name and I'll send you instructions. My thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

[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