- Boost - lists.preview.boost.org

Locating Visual Studio 2017 on disk
by Andrew Pardoe 20 Apr '17

20 Apr '17

Folks, We had a number of conversations about the fact that VS 2017 could be installed in any location, or multiple locations, and no longer created a registry key pointing to an install location. There's also the problem that an installation of VS 2017 may or may not contain C++ tools (as was the case with VS 2015.) The solution proposed by the VS team-creating a tool called VSWhere-was inadequate for some scenarios such as Boost's because it would have required either caching a binary in your source enlistment or compiling code to locate the compiler. A number of people on this list asked for a more straightforward solution. I'm happy to tell you that your feedback was heard. We're going to start shipping the VSWhere tool in a known location on any machine that has VS 2017. More details can be found in this blog post: https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed… This doesn't fix the problem for all the versions of VS 2017 that are installed already. And this doesn't help our version numbers to make any more sense (although I'm pushing to fix that as well.) But at least in the future you'll be able to locate VS installs from a scripted environment. Thanks for being loud and reaching out to us. As always, I'm happy to help you with any issues you might have with MSVC-just ask. Andrew Pardoe MSVC compiler & tools

1 0

[stacktrace] Please for into boostorg repo
by Antony Polukhin 20 Apr '17

20 Apr '17

Hi, Stacktrace library was accepted into the Boost http://www.boost.org/community/review_schedule.html Please fork the repo https://github.com/apolukhin/stacktrace into boostorg and give me admin rights to that repo. -- Best regards, Antony Polukhin

2 4

Boost Library Incubator Statistics
by Robert Ramey 20 Apr '17

20 Apr '17

In the course of updating the Boost Library Incubator website, I gathered some summary statistics which some might find interesting. 40 Number of libraries submitted 2 libraries not accepted into the incubator of lack docs, test, etc. 11 libraries reviews by boost 9 accepted 2 rejected All in all, I'm thinking these numbers aren't too bad for boost and the incubator. I would like to see more submissions - but the submissions we've received seem to be better than average quality and worthy of consideration. Hopefully this has made the review process more efficient. A couple of libraries have also been accepted (and rejected) without having been placed in the incubator. The number is small. I think this validates the incubator as useful, but not necessary and libraries authors should continue to be encouraged, but not required, to submit library candidates to the incubator. Other than the above, I'm not going to try to draw any conclusions from the above admittedly anecdotal data. I would also remind boosters that if you're logged into the incubator, you can display statistics on viewership for a particular library by using the "Display Statistics" button on the library page. This is a crude but someone engaging way to get an idea of how many people have looked at the library page. The attached shows visits to the safe numerics library page in the last 90 days. Robert Ramey

3 5

List-Id mail header
by Christoph Ludwig 20 Apr '17

20 Apr '17

Hi, starting yesterday, the List-Id header in the mails I get from the Boost mailing list changed. It used to be: List-Id: Boost developers' mailing list <boost.lists.boost.org> Now it is: List-Id: Boost developers' mailing list <boost.wowbagger.crest.iu.edu> Due to this change, the mail filter I have used for years fails to identify the messages as boost mailing list traffic. Therefore, the messages end up in my regular inbox instead of the dedicated folder I have for the mailing list. Of course, I can easily update my mail filter, that's no big deal. I just want to know: Did I miss an announcement, was this change intended? Will the List-Id use the wowbagger identifier from now on? Cheers, Christoph

2 1

[release] Boost 1.64.0
by Rene Rivera 20 Apr '17

20 Apr '17

Release 1.64.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/history/version_1_64_0.html> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.64.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Rene Rivera, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

2 1

[release] Boost 1.64.0 Release Candidate 1
by Rene Rivera 19 Apr '17

19 Apr '17

The release candidates for the 1.64.0 release are now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.rc.1/> The SHA256 checksums are as follows: 49c6abfeb5b480f6a86119c0d57235966b4690ee6ff9e6401ee868244808d155 boost_1_64_0_rc1.7z 7bcc5caace97baa948931d712ea5f37038dbb1c5d89b43ad4def4ed7cb683332 boost_1_64_0_rc1.tar.bz2 0445c22a5ef3bd69f5dfb48354978421a85ab395254a26b1ffb0aa1bfd63a108 boost_1_64_0_rc1.tar.gz b99973c805f38b549dbeaf88701c0abeff8b0e8eaa4066df47cac10a32097523 boost_1_64_0_rc1.zip 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. -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

9 8

[Trac] Spam and suspicious attachments
by Mateusz Loskot 19 Apr '17

19 Apr '17

Hi, I'm not sure what is the correct admin contact to report spam on Trac, so posting here. Number of suspicious attachments (.exe, .jpg) have been submitted to this ticket during recent period of 3 years https://svn.boost.org/trac/boost/ticket/8070 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[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

[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

[CallableTraits] The formal review begins today
by Louis Dionne 13 Apr '17

13 Apr '17

Dear Boost community, The formal review of Barrett Adair's CallableTraits library begins today, April 3rd, and ends on April 12th. CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures. You can find the documentation of the library here: http://badair.github.io/callable_traits/doc/html/index.html and the GitHub repository here: https://github.com/badair/callable_traits We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost, and conditions for acceptance if any - 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? We await your feedback! Regards, Louis

12 28

Formale Review: Callable Traits
by Peter Dimov 13 Apr '17

13 Apr '17

I think that the Callable Traits library should be ACCEPTED. The design of the library is sound, although I'm not fond of the ad-hoc metaprogramming part in "parameter list features". This is no fault of the author though, as without a modern type-metaprogramming library in Boost, everyone has to solve this problem in some way. Still, I think that most of these should be removed. Getting the arguments as a tuple that includes the class type as a first parameter raises the obvious question of void(foo::*)(float, char, int) -> tuple<foo&, float, char, int> void(foo::*)(float, char, int) & -> tuple<foo&, float, char, int> I understand why that is, but it still makes args lossy and the original can't be recreated from the tuple. Trailing varargs also have the same problem, as (float) and (float, ...) map to the same tuple. The obvious theoretically consistent approach here is void(foo::*)(float, char, int) -> tuple<foo, float, char, int> and void(float, ...) -> tuple<float, ct::varargs_t> which would be fully reversible but could possibly be less convenient in practice. I've a feeling that it might also be useful to provide an extractor that, for member pointers, returns just the arguments without the class. In "member qualifier features", I'm missing remove_member_cv_ref (obvious semantics) and copy_member_cv_ref (copies cv+ref from one member pointer to another.) In "member pointer features" we have the same problem in qualified_parent_class_of as in args, void(foo::*)() -> foo& void(foo::*)() & -> foo& It makes more sense for the first to yield 'foo', although this again may make the trait less convenient in practice. It would also _probably_ make sense to provide apply_qualified_member_pointer, which, given void(float) and foo const&, would yield void (foo::*)(float) const&. I did not look at the implementation. I ran the test suite on Windows under Cygwin g++ 5 in 11/14/1z, Cygwin clang 3.9 11/14/1z, msvc-14.0, msvc-14.1. The tests passed. Took a look at the tests themselves, the coverage looks excellent. The reference documentation is very good, although as already noted, it uses the terms of art "implementation defined" and "undefined behavior" incorrectly, this must be fixed. The non-reference portion is a bit thin. It would be improved considerably by presenting a few real-world use cases. All in all, a solid library that solves a real problem, even though the problem remains somewhat of a mystery for the uninitiated. :-)

4 4

Libraries and C++ compliance
by Edward Diener 12 Apr '17

12 Apr '17

I would like to ask people who present new libraries to Boost, in whatever stages they are, to please specify in the documentation to the library and/or in messages regarding the library, what level of C++ compliance is needed to use the functionality of that library. This plea is not being directed at any particular current library being mentioned by anyone on the mailing list, but is a general plea regarding developers and their efforts. I realize it is a real pain that C++ as a language, and as it continues to evolve, has a number of popular levels of C++ compliance. This is largely because C++ is offered by a number of different vendors in a number of different supported releases, each particular implementation supporting a number of levels of C++ compliance and sometimes only partially supporting a particular level of C++ compliance. But given this sometimes difficult situation I do not see it as enough for library docs/information to simply say "this library supports some-vendor/some-release" because this is actually fairly meaningless to me when I know that "some-vendor/some-release" supports a number of levels of C++ compliance through some compiler parameter ( often -std=something ). Therefore docs/information of "the library supports "some-implementation" or "the library is compliant with "more than one level of C++ compliance" tells me as much as if some one told me that the moon is yellow. So I am begging, pleading, entreating library authors to be specific about the C++ features or the C++ level of compliance needed to use their library, even if it is just a one-liner that succinctly explains what the end-user needs to know. Furthermore, for any given library could we please have specific information about what will happen if I use the library, or some feature of the library, without the desired minimum level of C++ compliance. While I would assume compile-time compiler errors as the norm another possibility, especially given the excellent support in Boost Config to compiler conformance, are more readable preprocessor errors. Finally a library might offer some level of advanced C++ compliance but fall back to a lower level if possible. Please, please library authors this is important. No end-user or tester of your library wants to spend extended time trying to figure out why some compile fails when the answer turns out simply to be one of inadequate C++ conformance level for a particular compiler implementation being used with a particular level of conformance.

13 29

Re: [boost] [proposed][histogram]
by Bjorn Reese 12 Apr '17

12 Apr '17

On 04/12/2017 11:37 AM, Hans Dembinski via Boost wrote: > The library implements a histogram class (a highly configurable policy-based template) for C++ and Python in C++11 code. Histograms are a standard tool to explore Big Data. They allow one to visualise and analyse distributions of random variables. A histogram provides a lossy compression of input data. GBytes of input can be put in a compact form which requires only a small fraction of the original memory. This makes histograms convenient for interactive data analysis and further processing. Given that the compression is lossy, I am wondering how it compares with a distribution estimator like: https://arxiv.org/abs/1507.05073v2 A common use-case when collecting numerical data is to determine the quantiles. Boost.Accumulators contains an estimator (extended_p_square) for that. The advantage of such estimators are that they execute in constant time and with constant memory usage, where the constant depends only on the required precision. PS: I am aware that this is a non-trivial question, so I do not expect an answer.

3 4

[proposed][histogram]
by Hans Dembinski 12 Apr '17

12 Apr '17

Dear Boost community, after another year of work, I hope to raise your interest once again in a much improved version of "histogram", a library proposed for inclusion in Boost. https://github.com/HDembinski/histogram http://blincubator.com/bi_library/histogram-2/?gform_post_id=1582 The library can be build either with b2 or cmake. It compiles successfully with several versions of clang and gcc and has 99 % test coverage (the remaining 1 % are basically un-hittable branches). Boost-style documentation is available. The library implements a histogram class (a highly configurable policy-based template) for C++ and Python in C++11 code. Histograms are a standard tool to explore Big Data. They allow one to visualise and analyse distributions of random variables. A histogram provides a lossy compression of input data. GBytes of input can be put in a compact form which requires only a small fraction of the original memory. This makes histograms convenient for interactive data analysis and further processing. A histogram implements a quantisation of a space of input values. The space is divided into non-overlapping cells. Instead of remembering the exact values of a tuple in that space, one just increases a counter in the corresponding cell. This is the lossy compression, you only remember the count in the cell and not the original values. There are subtleties related to the counting if you want it to be safe and efficient. The library handles this for you. The standard policy implements intelligent counters which are fast, conserve memory, and are guaranteed to not overflow or get capped (capping happens when you use floating point numbers to count, like some implementations do). This is one of the two main feature of the library. The other main feature is that the library allows you to seamlessly create one or multi-dimensional histograms using various schemes to divide the input space. A so-called axis class handles the division into cells along each dimension. There are several ways how you might want to define the cells that divide the input space, and library offers you interesting options. For example, if one of your inputs is an angle, the library provides a special axis class for periodic input values. What's new: - Static polymorphism: The original version of the library solely used dynamic polymorphism to support different axis classes. This variant still exists, but the current version also allows you to use static polymorphism, implemented internally with boost::mpl and boost::fusion. This provides a speed-boost, which makes this library faster than the open-source competitors I tested (CERN's ROOT framework, the GSL, and numpy.histogram), in addition to the enhanced flexibility. - Arbitrary-precision counters: Counter overflow is now completely avoided by switching automatically to boost::multiprecision::cpp_int when the capacity of standard integer types is exhausted. - Extensibility: The library is now much more extensible and configurable. All relevant behaviour can be exchanged by using another (possibly user-defined) policy. The library provides default trade-offs that should work for almost everybody, but you can chose your own trade-offs. The new features were inspired by comments I got from the community. Now I am again at a point where I see the library in a very solid state. Best regards, Hans

1 0