April 2018 - Boost - lists.boost.org

Library for printing STL containers
by Eric Curtin 14 Apr '18

14 Apr '18

Hi Guys, I have tried to contact the developer of this neat little library. It allows you to use streams such as ostringstreams and couts with various STL containers, without the boilerplate of any loops to get all the contents. I will likely fork and maintain it as I have tried (and failed) to contact the developer. https://github.com/louisdx/cxx-prettyprint If I cleaned it up, could we consider it for boost inclusion? It is already under boost open source license.

2 1

MSVC now correctly reports __cplusplus
by degski 12 Apr '18

12 Apr '18

https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-repor… degski

1 0

[release] Boost 1.67.0 Release Candidate 1
by Daniel James 11 Apr '18

11 Apr '18

The release candidates for the 1.67.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.67.0/source/> The SHA256 checksums are as follows: 289d55fc90b637781018c4babe3ba83244175aa539b54bc687529a65e352e713 boost_1_67_0_rc1.7z 0d13e038f8f402ea0d811397876c8e6f2a2352c170f90d0a42bb61dcec3f86fc boost_1_67_0_rc1.tar.bz2 5d25d1cdf6f7061f25463f59ce2e5c9e1cecfece90d86a04513de386c86fbb5e boost_1_67_0_rc1.tar.gz ae8d461a8573d24813c92e3daf1f7832908d1845820d94b77243d6cd06197635 boost_1_67_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.

4 5

[build] Broken doc links
by Gavin Lambert 11 Apr '18

11 Apr '18

Prompted by the thread "Toolset version for Visual Studio 2017 15.6.3" over in the user list, I was looking through some Boost.Build documentation when I found some dead links and other weirdness. Boost.Build's github page links to https://www.boost.org/build/, which appears to be fully working. On https://www.boost.org/doc/libs/1_66_0/more/getting_started/windows.html, under "5.2.1 Install Boost.Build" it links to https://www.boost.org/doc/libs/1_66_0/tools/build/index.html, which appears to be a versioned clone of the above. But at that page, the "Documentation" link points at https://www.boost.org/doc/libs/1_66_0/tools/build/doc/html/index.html, which 404s. Back in "Getting Started", in "5.2.2 Identify Your Toolset" it first links directly to https://www.boost.org/build/doc/html/bbv2/reference/tools.html (which is now an unversioned link, but does work), and then to https://www.boost.org/doc/libs/1_66_0/doc/html/bbv2/installation.html (which is a versioned link that also works). So it's not very consistent. Putting these things together, it looks like the "right" root page for the versioned documentation should be https://www.boost.org/doc/libs/1_66_0/doc/html/bbv2.html, although that lacks some user-friendliness. (And it also links to https://www.boost.org/boost-build2 for yet another URL variation... although that does redirect to https://www.boost.org/build/ at least.)

2 2

please integrate patches for Boost.Gil and Boost.Graph
by Brook Milligan 10 Apr '18

10 Apr '18

I am not sure what the correct procedure for this is, but there are at least two old patches that would improve Boost.Gil and Boost.Graph. I would greatly appreciate it if someone integrates these. I have been using these for some time now with no detrimental effects. The patch to Boost.Gil corrects clearly incorrect code. The patch to Boost.Graph solves a problem that should never have been in the original design in the first place. Since it expands the acceptable set of arguments to cover the full range of values any user would expect and has the original semantics for cases that worked before, as far as I can see there can be no effect on existing user code. Thank you very much. Cheers, Brook See the following: - https://lists.boost.org/Archives/boost/2013/02/200721.php - https://svn.boost.org/trac10/ticket/7270 - https://svn.boost.org/trac10/ticket/9517 - https://svn.boost.org/trac10/attachment/ticket/9517/gil_channel_algorithm.p… - https://svn.boost.org/trac10/ticket/13397 --- boost/gil/channel_algorithm.hpp.orig 2018-02-23 22:45:42.000000000 -0700 +++ boost/gil/channel_algorithm.hpp 2018-03-11 22:05:31.000000000 -0600 @@ -25,6 +25,7 @@ #include "gil_config.hpp" #include "channel.hpp" +#include <limits> #include <boost/mpl/less.hpp> #include <boost/mpl/integral_c.hpp> #include <boost/mpl/greater.hpp> @@ -51,7 +52,7 @@ template <typename UnsignedIntegralChannel> -struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,-1> {}; +struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,std::numeric_limits<UnsignedIntegralChannel>::max()> {}; template <> struct unsigned_integral_max_value<uint8_t> : public mpl::integral_c<uint32_t,0xFF> {}; Allow dimensions to have length >= 1, rather than > 1. See https://svn.boost.org/trac10/ticket/11735. --- boost/graph/grid_graph.hpp.orig 2017-12-13 16:56:43.000000000 -0700 +++ boost/graph/grid_graph.hpp 2018-04-07 09:33:56.000000000 -0600 @@ -630,15 +630,17 @@ // If the vertex is on the edge of this dimension, then its // number of out edges is dependent upon whether the dimension - // wraps or not. - if ((vertex[dimension_index] == 0) || - (vertex[dimension_index] == (length(dimension_index) - 1))) { - out_edge_count += (wrapped(dimension_index) ? 2 : 1); - } - else { - // Next and previous edges, regardless or wrapping - out_edge_count += 2; - } + // wraps or not, but only if the length is > 1. + if (length(dimension_index) > 1) { + if ((vertex[dimension_index] == 0) || + (vertex[dimension_index] == (length(dimension_index) - 1))) { + out_edge_count += (wrapped(dimension_index) ? 2 : 1); + } + else { + // Next and previous edges, regardless or wrapping + out_edge_count += 2; + } + } } return (out_edge_count);

4 7

[concept_check] Reference page concept links out-of-date
by Spencer Collyer 09 Apr '18

09 Apr '18

Not sure if this has been reported before, but any links on the Reference page of the concept_check library that point to SGI.com now take you to a page that says 'SGI.com Tech Archive Resources now retired'. Regards, Spencer Collyer

5 4

Reducing dependencies
by Antony Polukhin 08 Apr '18

08 Apr '18

Hello, I've noted that many libraries depend on container_hash while it depends only on a single header from Boost.Detail library https://pdimov.github.io/boostdep-report/master/module-levels.html Can we move "boost/detail/container_fwd.hpp" into Boost.Core or into Boost.ContainerHash? This will break the circular dependency, move the Boost.ContainerHash on level 4 and improve levels of Intrusive, Container, CircularBuffer, Unordered, Algorithm, Test, TypeIndex, Any, Function, Functional, ScopeExit, Signals, MultiArray, Variant. -- Best regards, Antony Polukhin

6 12

[release] 1.67.0 mostly closed for release candidate
by Daniel James 07 Apr '18

07 Apr '18

The master branch is now closed for all changes except by permission for the release candidate. We're expecting potential fixes for build, context and a documentation update for ptr_container. Please let us know if there are any other fixes that you want to include in the release. Thanks, -- The Boost Release Team

5 9

mkmakefile
by Ggh 06 Apr '18

06 Apr '18

Hi! is anyone interested in developing this code further? pls have a look at: http://www.multi.fi/~ghaga http://www.multi.fi/~ghaga/mkmakefile/ anyone? Ty, Greg

4 6

[ptr_container] Docs not updated to reflect std::auto_ptr -> std:unique_ptr changes
by Edward Diener 04 Apr '18

04 Apr '18

An issue was recently created that while ptr_container now supports std::unique_ptr where appropriate and no longer supports std::auto_ptr where it has been removed from the C++ standard, the docs were never updated to reflect this change. I thought it would be worthwhile mentioning this as we go to the 1.67 release. A contributo is preparing a PR to correct this issue, and I will review as a member of CMT once the PR is submitted. I don't mean this as a way to delay the new release but I thought I should bring this up in the mailing list so others know this is the case.

2 1

[1.67] Missing include in Boost.Graph
by Denis Davydov 04 Apr '18

04 Apr '18

Dear all, 1.67.0.beta1 has a regression of missing include in Boost.Graph which prevents deal.II https://www.dealii.org <https://www.dealii.org/> project from building. Even though the file was not modified since 2015, it’s a regression as we have not had this issue with previous versions of boost. The one-liner fix is here https://github.com/boostorg/graph/pull/104 <https://github.com/boostorg/graph/pull/104> I would appreciate if you could merge it prior to 1.67.0 release. ps. https://github.com/boostorg/graph/pull/101 <https://github.com/boostorg/graph/pull/101> is a better way to fix it but as suggested in https://svn.boost.org/trac10/ticket/13505#comment:4 <https://svn.boost.org/trac10/ticket/13505#comment:4> this might not get merged into 1.67.0, which would be pity. Regards, Denis

3 2

Build breaking changes
by Antony Polukhin 03 Apr '18

03 Apr '18

Hello, I've just noted that building Boost from master stopped working: [00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release architecture=x86 link=static --with-program_options --with-filesystem --with-system --with-test --with-atomic --with-thread --with-timer --with-date_time --with-chrono --with-regex --with-random --with-context stage [00:16:52] Performing configuration checks [00:16:52] [00:16:52] - default address-model : 32-bit [00:16:53] - default architecture : x86 [00:16:53] - symlinks supported : yes (cached) [00:16:54] - C++11 mutex : yes [00:16:55] - has_icu builds : no [00:16:55] - BOOST_COMP_GNUC >= 4.3.0 : yes [00:16:55] - C++11 mutex : no [00:16:56] - has_icu builds : no [00:16:56] - BOOST_COMP_GNUC >= 4.3.0 : no [00:16:56] error: Name clash for '<pstage\lib>libboost_atomic.a' [00:16:56] error: [00:16:56] error: Tried to build the target twice, with property sets having [00:16:56] error: these incompatible properties: [00:16:56] error: [00:16:56] error: - <address-model>64 [00:16:56] error: - <address-model>32 [00:16:56] error: [00:16:56] error: Please make sure to have consistent requirements for these [00:16:56] error: properties everywhere in your project, especially for install [00:16:56] error: targets. [00:16:56] [00:16:56] Command exited with code 1 Previously this build command worked fine. Full log available at https://ci.appveyor.com/project/apolukhin/boost-cookbook/branch/second_edit… Is this an intended breaking change?

12 21

Debate until Decision
by James E. King, III 03 Apr '18

03 Apr '18

I'm going to float some thoughts about how the group makes decisions below. I'm not suggesting a specific course of action, but I would like people to think about how these ideas can be used to improve Boost development. Recent discussions about default address-model, and past discussions about issues like cmake and CI build improvements (like whether or not to purchase more build slaves from travis or appveyor), and topics about legal use of code snippets leads me to the following conclusion: 1. We are geographically, culturally, and vertically distributed and have highly varying viewpoints. 2. We are all very good at expressing our viewpoint about various topics. 3. We collectively need to improve our skill at coming to a group decision and moving forward. Folks generally have individual control over their respective maintained repositories in the current structure. There are many topics that generally affect all of the repositories, such as the ones I mentioned previously, that affect all of us. At my most recent startup company we implemented an effective "Debate until Decision" mechanism by which: 1. The issue is discussed. (We do this well) 2. A decision is made and implemented (We do not seem to do this well): Not everyone will be happy with the outcome. Folks should not attempt to undermine the outcome after decision. The issue can be raised again if new information is brought to light. How is a decision made? Typically in a meeting where people vote face-to-face. For a group like this, voting would be done online with a time limit. Who can vote? That's a good question. In this environment it may fall to the group of folks who are maintainers of an affected repository. I don't necessarily have a good answer for that, as I am relatively new to the group. Some folks have been here for 10+ years and may feel differently that seniority should have a say. I don't know. What are the benefits of this? Simply: *Things get done.* Look at the cmake discussion, or the CI build job discussion, or the current address-model discussion. These need to be finished, agreed to, and implemented (or not), and everyone moves forward. The Apache Software Foundation maintains a fairly well documented structure for each project, with a project management committee consisting of a chair and members who have equal voting rights, however said group's primary function is to identify and grow the team of developers who have commit privileges. The committers as a whole vote on issues that are project-wide, like "should we split into multiple repositories", or "should we move to another source code control environment"? This mechanism could also be applied to how folks are brought into maintainer status for a repository, or how a library enters the CMT. If you look at the bug backlog in trac for some one the libraries, it's pretty clear that they are not properly maintained. The issue may be discussed, but then dropped and forgotten, and no action is taken to remedy it. When repositories have pull requests open for years, or a backlog of 100 defects going back 10 years, there's a very unhealthy problem for that project that needs to be addressed. It may be a similar structure that will work well here. Folks may disagree. This will be debated, certainly, as folks probably have varying opinions about how much structure is needed or desired. I simply hope this leads to an effective discussion about how this group identifies deficiencies, solves them, and moves forward. Any group large or small can benefit from examination and improvement of processes, including ours. Thanks, Jim

5 5

[ineterprocess] managed mapped file - recovery from process failure
by Assaf Ben-amitai 03 Apr '18

03 Apr '18

Hi, I have noticed that if a process is killed while it's allocating memory from a managed file, later loading of the managed file may segfault (even in read-only mode). A. What is the expected behaviour in this case? B. Should such a segfault be considered as a bug or is it the case that the user is not supposed to use the managed file after process failure? C. If unsupported, any pointers on efforts to improve this? Thx, Assaf

2 1

[cmake] Where to discuss CMake in Boost?
by Mateusz Loskot 02 Apr '18

02 Apr '18

Hi, TL;TR: Which is the right mailing list to discuss CMake in Boost? Numerous CMake discussions happened here lately which, I think, were mostly about the grand Boost vs CMake strategy, politics. The boost-cmake ml has been quiet for years now, according to its archives. https://lists.boost.org/mailman/listinfo.cgi/boost-cmake Whereas, there has been lots of activity in development of CMake for various aspects: to use CMake inside Boost. to use CMake to build Boost, etc. That is https://github.com/boost-cmake where, in particular, I'm interested in https://github.com/boost-cmake/bcm Where can I ask *technical* questions about those to avoid polluting wrong list? Best regards. -- Mateusz Loskot, http://mateusz.loskot.net

5 10