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

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[foreach][polygon][xpressive][bimap][ptr_container][gil][assign][typeof][msm] PRs for removing executable attribute for files
by Edward Diener 08 Mar '18

08 Mar '18

The following libraries still have PRs, which I have previously submitted, for removing the executable attribute for one or more files: foreach polygon xpressive bimap ptr_container gil assign typeof msm None of these PRs affect anything other than the file attribute, so no testing is needed AFAICS since no code changes. If the maintainers of the above libraries, or someone else with write access to these libraries, can merge the appropriate PR to 'develop', and then merge 'develop' to 'master', we can get rid of having any files with their executable attribute set in the next release.

5 13

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

[Root Pointer] Deterministic C++ memory manager (update)
by Phil Bouchard 26 Jan '18

26 Jan '18

Greetings, I wanted to give an update to the community regarding the memory manager I wrote called: Root Pointer. I now have a working template to solve all memory leaks in C++ and C but both requires some meta data generator. The code can be found here; it is working but not polished: https://github.com/philippeb8/root_ptr In this code we can find: - node_ptr: main class of the smart pointer / memory manager. - root_ptr: generic derived class that includes an "iterator" and a pointer to the name of the instance (for debugging purposes). Also I commented some code that logs the exact location of the memory leak. Furthermore I would like to bring some observations that I found in the C and the C++ language: - Pointers and iterators are not the same; i.e. pointers should point to allocated blocks only and shouldn't have arithmetic operators while iterators shouldn't be used to deallocate anything. - C pointers can only point to dynamic arrays (size known at run-time). - C++ pointers can point to both inherited objects and static arrays (size known at compile-time). This creates a problem (see attached: array_inherited_pointer.cpp). - std::array<T> should have constructors with T objects that have no default constructor. Lastly, before I submit anything, I will have to propose a way to apply a template function to all non-static member variables of a class. This will require implicit meta data generation. This idea is not new as other libraries such as Qt is based on meta data and they certainly could make us of this. For the moment I have a parser that does the job correctly by specializing a boost::proxy() template function but eventually this will have to be integrated into the standards. Hopefully this is an important milestone! Regards, Phil Bouchard www.fornux.com

2 5

[config] Supporting newer compilers: what does it take?
by Olaf van der Spek 22 Jan '18

22 Jan '18

Hi, What does it take to support new compilers, especially MSVC? 15.6 Preview 1 has been released now. Is some documentation or policy regarding test runners etc available? https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-… Gr, -- Olaf

1 1

Informal CMake meeting at CPPCon
by Robert Ramey 12 Jan '18

12 Jan '18

Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject. Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese This was a small but I think a representative group. After some preliminary back and forth, I think we agreed: a) Nothing was going change regarding the current build system until there was a real alternative in place. b) That we should support serious proposals to implement CMake support within boost. c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process. e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take. I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way. My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some. Robert Ramey

9 18

Re: [boost] seeking endorsement for histogram library
by Bjorn Reese 09 Jan '18

09 Jan '18

I endorse boost.histogram.

6 11

[hash] Extract module from functional + std::hash_combine
by Daniel James 06 Jan '18

06 Jan '18

Hi, I'm planning to extract hash from functional into its own module, as that will apparently break the circular dependencies that functional is part of. Any objections? Also, any opinions on what the module should be called? 'hash' might suggest a more general purpose hash function, so maybe it should be called something more specific. Daniel

10 29

Interest for a Fixed Point Arithmetics library
by Julien Vernay 03 Jan '18

03 Jan '18

Hello everybody. I am working on a project that needs and can use fixed point numbers, so I started searching for a library implementing fixed point numbers, but I didn't find anything. So I was wondering if people would need fixed point arithmetics, and here I am. The aim of this FixedPointNumber is to fix the point at compile-time using template, and having another template argument for the underlying type. So we have : template<typename T, size_t N> class FixedPointNumber { T value; public: //interface }; The N last bits of value is the decimal part : so to convert a FixedPointNumber to an int, we need only to use a bitshift operator (and same for construction from int). sizeof(FixedPointNumber<T,N>) == sizeof(T) , so there is no overhead in this implementation. Arithmetic and relational operators will be implemented. Multiplication needs one int multiplication and one bit shift. Division needs one int division and one bit shift. There is only one value for zero. Sign can be extracted with Most Significant Bit. I have already a basic implementation but if it interests more people I will do a proper implementation. Thank you for reading !

4 7

[multiprecision] Help needed with strange constexpr slowdown
by John Maddock 03 Jan '18

03 Jan '18

Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary: Given: #include <iostream> #include <boost/multiprecision/cpp_int.hpp> using namespace std; using namespace boost::multiprecision; int main() { __int128_t i =0; __int128_t j =0; int256_t sum =0; for (; i <1e9; i +=19, j +=13) { int256_t diff = j; sum += i * diff; } std::cout <<"Result: " << sum << std::endl; return 0; } There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x. I've tracked this down to the constexpr default constructor for int256_t (which is called inside operator* to create a temporary for the result), if I make the default constructor non-constexpr by removing BOOST_CONSTEXPR from any of: number.hpp:44 (number()) cpp_int.hpp:1077 (cpp_int_backend()) cpp_int.hpp:501 (cpp_int_base()) cpp_int.hpp: 435 (cpp_int_base::data_type()) Then the slowdown disappears. All the line numbers refer to current develop BTW. gcc-7 is better, but I notice it still generates different code if the constructor is constexpr - that greatly surprises me to be frank - is there something I'm missing about constexpr-ness that could cause this? Confused yours, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 3

Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 01 Jan '18

01 Jan '18

On Sun, Oct 8, 2017 at 5:38 PM, Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> wrote: > Now, moving on... given that you have __not__ answered how your parser's > design[1] compares to the parser I've developed I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library. Therefore, I have made the interface as simple as possible, exposing only the minimum required necessary to achieve these goals which the majority of users want: * Read the header first, if desired * Feed Asio style buffer sequences into the parser * Set independent limits on the number of header and body octets * Optional fine-grained receipt of chunked body data and metadata The design of basic_parser (the use of CRTP in particular) is meant to support the case where a user implements their own Fields container, or if they want a bit more custom handling of the fields (for example, to avoid storing them). Like all design choices, tradeoffs are made. The details of parsing are exposed only to the derived class. Complexities are hidden from the public-facing interface of `basic_parser`. Implementing a stream algorithm that operates on the parser is a straightforward process: template< class SyncReadStream, class DynamicBuffer, bool isRequest, class Derived> std::size_t read(SyncReadStream& stream, DynamicBuffer& buffer, basic_parser<isRequest, Derived>& parser, error_code& ec) { parser.eager(true); if(parser.is_done()) { ec.assign(0, ec.category()); return 0; } std::size_t bytes_transferred = 0; do { bytes_transferred += read_some( stream, buffer, parser, ec); if(ec) return bytes_transferred; } while(! parser.is_done()); return bytes_transferred; } > [1] at most it hides behind a “multiple people/stakeholders agree with me” > __shield__ There's no hiding going on here. One can only measure the relative success of designs based on the feedback from users. They opened issues, and I addressed their use-cases, sometimes with a considerable amount of iteration and back-and-forth as you have seen in the GitHub issues quoted in the previous message. Now, I don't know if the sampling of users that have participated in Beast's design are representative of the entire C++ community. However, I do know one thing - if GitHub stars are any measure of the sample size of the participants, then Beast is off to a good start. Here's a graph showing the number stars over time received by boostorg/beast, tufao, and Boost.Http (the last 2 libraries having you as the author I believe): <http://www.timqian.com/star-history/#boostorg/beast&BoostGSoC14/boost.http&…> (Note that the HTTP+WebSocket version of Beast was released in May 2016). We need to be careful interpreting results like this of course so perhaps we should look at different metrics. Here are the links to the number of closed issues for Beast, tufao, and Boost.Http: 502 Closed issues in Beast: <https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aclosed> 38 Closed issues in tufao <https://github.com/vinipsmaker/tufao/issues?q=is%3Aissue+is%3Aclosed> 13 Closed issues in Boost.HTTP, from 6 unique users not including the author <https://github.com/BoostGSoC14/boost.http/issues?q=is%3Aissue+is%3Aclosed> Again we have to be careful interpreting results like this. But it sure looks like there is a lot of user participation in Beast. If approval from a large number of stakeholders is not a compelling design motivator then what is? > This tutorial is full of “design implications” blocks where I take the time > to dissect what it means to go with each choice. Thus far, no one has asked for more fine grained access to incoming HTTP tokens in the manner of `code::method` and `code::request_target`. If this becomes something that users consistently ask for, it can be done by changing the requirements for the derived class for `basic_parser`. This way, details about HTTP parsing which most people don't care about will not leak into the beast::http:: namespace. Such a change would not affect existing stream algorithms on parsers. Thanks

5 17

Re: [boost] What hash functions should be included in a hypothetical Boost hash-v2 library?
by Bjorn Reese 31 Dec '17

31 Dec '17

On 12/31/17 01:28, Peter Dimov via Boost wrote: > What (non-cryptographic) hash functions should a hypothetical future > Boost hash library contain? Have clear winners emerged by now? Which > ones do people prefer? I vote for FNV hashes: https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function

1 0

What hash functions should be included in a hypothetical Boost hash-v2 library?
by Peter Dimov 31 Dec '17

31 Dec '17

What (non-cryptographic) hash functions should a hypothetical future Boost hash library contain? Have clear winners emerged by now? Which ones do people prefer? SipHash is basically a given, but it's not optimized for speed.

5 6

Removing hash from Boost.Functional broke modules
by James E. King, III 28 Dec '17

28 Dec '17

See: https://github.com/boostorg/type_index/issues/18 There is no forwarding header to keep things compatible. - Jim

2 1

Maintenance of Boost.DateTime
by James E. King, III 28 Dec '17

28 Dec '17

The backlog for Boost.DateTime in trac has over 130 issues; the project is holding on to very old backwards compatibility code (pre-boost-1.33.0 i/o facets), and the CI builds do not currently have appveyor, codecov.io, or coverity scan integration. It needs a proper maintainer in order to resolve these issues, so I would like to ask for that privilege. Thanks, Jim

1 0

Appveyor and Travis CI notifications of Boost library tests
by Edward Diener 26 Dec '17

26 Dec '17

Is there a way to tell Appveyor or Travis CI to send notifications of its Build runs of Boost libraries to someone other than myself ?

4 7

Candidate for 1.66.1, if there is one
by James E. King, III 25 Dec '17

25 Dec '17

In Boost 1.66.0, there was a fix to date_time for the year 2038 problem: https://github.com/boostorg/date_time/pull/35 The serialization code in date_time had no static assertions enforcing the size of data values, and adding proper versioning support was missed in the release by myself and not picked up in the code reviews. As a result, serializing in anything written by earlier boost versions fails for date_time related structures, which might be considered serious enough to justify a 1.66.1 release. (We could also get the latest msvc compatibility in there I suppose...) I'm adding proper versioning right now, however Boost 1.66.0 will remain a problem since it serializes in/out as Version 0 with 64-bit values; and 1.65.1 serializes in/out Version 0 with 32-bit values so I'm not certain there will be a way to detect this issue. The issue is recorded in github here: https://github.com/boostorg/date_time/issues/56 Any additional thoughts are appreciated. I'm looking at adding a test to write out a version 0 and then read it in when the current version is 1, but I don't want to add test-only support code to the headers that get shipped, so if anyone can point me at a current example unit test that writes out a "n-1" version and then reads in a "n" version with boost::serialization I would appreciate it. Thanks, Jim

9 22

Getting Started
by ishan garg 25 Dec '17

25 Dec '17

Hello everyone, I am new to OpenSource Development. I know basics of C++ and acquainted with it's STL. I have basic knowledge of DSA as well as few git commands (clone, push, commit, etc). I wanted to know how can I start contributing to BOOST library? Thanks in Advance -- Regards, Ishan Garg

2 1

library maintainer list
by Robert Ramey 24 Dec '17

24 Dec '17

I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?). Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now. Robert Ramey

6 10

regarding mailing list traffic
by Mudit Sharma 22 Dec '17

22 Dec '17

Dear All, I have recently not been receiving the daily Boost mailing list digest, is there some maintenance work going on ? Thanks! M

2 1

[date_time] Trac 13194 - %e posix time_input_facet specifier behavior
by James E. King, III 21 Dec '17

21 Dec '17

https://svn.boost.org/trac10/ticket/13194 Just looking at this one, and looking at the documentation, it states that %e is the same as %d however when the value is less than 10, a leading space is to be used instead of a leading zero. The example in the description has a flaw, I believe, and I commented on that. Do folks agree with my comment? Should parsing fail if it says "December 5" (with one space) and the format string is "%B %e"? Valid input would be "December 5" (with two spaces). I also found that the code blindly ignores delimiter specifiers, so I opened a github issue for it: https://github.com/boostorg/date_time/issues/53. Comments appreciated there as well. Thanks, Jim

2 2

[endian] undefined behaviour in boost.endian
by Arvid Norberg 21 Dec '17

21 Dec '17

Hi, I've submitted an issue to the github project for boost.endian. I'm starting to wonder if this is in fact not the preferred channel for reporting issues. There are at least two separate issues causing undefined behaviour to be invoked in boost.endian. The first one is fundamentally based on the assumption that if the target architecture is x86, the C++ alignment requirements don't apply. I've posted more details here: https://github.com/boostorg/endian/issues/21 with a proposed patch here: https://github.com/boostorg/endian/pull/22 The second issue involves shifting negative integers, both invoking implementation defined and undefined behaviour. I don't have a patch to fix the issue, just to extend the tests to exercise the problem, which is then detectible with the undefined behaviour sanitizer. Patch is here: https://github.com/boostorg/endian/pull/24 I would really appreciate it if someone could review these and/or suggest a better venue than github to propose patches. thanks! -- Arvid Norberg

3 2

[build] Currently broken with Xcode 8?
by John Maddock 20 Dec '17

20 Dec '17

Current develop appears not to build with XCode 8.0 causing Travis tests to fail, for example: https://travis-ci.org/boostorg/config/jobs/318188889 Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

5 6

[release] Boost 1.66.0
by Daniel James 19 Dec '17

19 Dec '17

Release 1.66.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 N new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.66.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.66.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, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

2 1

[release] 1.67.0 open for merging
by Daniel James 19 Dec '17

19 Dec '17

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[release] 1.66.0 post-beta merges
by Daniel James 19 Dec '17

19 Dec '17

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy>

14 32

[release] Boost 1.66.0 Release Candidate 2
by Daniel James 18 Dec '17

18 Dec '17

The second release candidates for the 1.66.0 release are now available at: <https://dl.bintray.com/boostorg/prerelease/> The in progress release notes are: <http://www.boost.org/users/history/in_progress.html> Library documentation is available at: <http://www.boost.org/doc/libs/1_66_0/> The SHA256 checksums are as follows: 596389389c005814ecb2a6b64c31dccd2c3e6fbc5a802b4dfada999ae5844628 boost_1_66_0_rc2.7z 5721818253e6a0989583192f96782c4a98eb6204965316df9f5ad75819225ca9 boost_1_66_0_rc2.tar.bz2 bd0df411efd9a585e5a2212275f8762079fed8842264954675a4fddc46cfcf60 boost_1_66_0_rc2.tar.gz e1c55ebb00886c1a96528e4024be98a38b815115f62ecfe878fcf587ba715aad boost_1_66_0_rc2.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.

12 31

boost-1.66.0 tag?
by James E. King, III 18 Dec '17

18 Dec '17

I just refreshed Boost.Uuid locally and don't see a boost-1.66.0 tag. I had assumed this would be added by the upstream build and release procedure? Am I supposed to make that tag? - Jim

2 2

[chrono][timer][release] Non-inline functions in inlined headers
by Daniel James 14 Dec '17

14 Dec '17

Hi, We've had a link problem reported. for this code on Visual Studio, using auto-linking: #include "boost\chrono.hpp" #include "boost\timer\timer.hpp" int main() { auto now = boost::chrono::steady_clock::now(); boost::timer::cpu_timer cput; return 0; } I haven't got the binaries installed yet, so I haven't reproduced it, but I think it's caused because timer now includes the chrono headers using BOOST_CHRONO_HEADER_ONLY, and in the chrono inlined headers not all functions are BOOST_CHRONO_INLINE. It looks like this problem was always in chrono, but BOOST_CHRONO_HEADER_ONLY was widely used enough for it to be detected. I'd quite like to fix this for 1.66.0, which requires either reverting the change to timer, or fixing the problem in chrono. The error is in chrono, but I'm more inclined to revert the change in timer for this release, as it's a less disruptive way of quickly fixing the problem. https://github.com/boostorg/timer/pull/5

3 8

Building only x86 /MDd and /MT on msvc 2017
by Fredrik Stax{ng 13 Dec '17

13 Dec '17

The docs says For instructions on how to build only specific variants, please ask on the Boost.Build mailing list. but I gmane gives a 411 for Boost.Build so I ask the question here. For 1.60.0 I used this cd modular-boost rem call .\bootstrap .\b2 headers .\b2 toolset=msvc variant=debug address-model=32 link=static threading=multi runtime-link=shared .\b2 toolset=msvc variant=release address-model=32 link=static threading=multi runtime-link=static Has this changed? -- Fredrik Stax\"ang | rot13: sfgk(a)hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET

1 0

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

linker error in 1.66 rc1 (regression from 1.65.1)
by Mark Incley 13 Dec '17

13 Dec '17

Hi, Using Visual Studio 2017 15.5, the following minimal test case causes a linker error with Boost 1.66 RC1 but builds fine with 1.65.1: Produces... 1>------ Build started: Project: aZ80, Configuration: Debug Win32 ------ 1>libboost_timer-vc141-mt-gd-x32-1_66.lib(cpu_timer.obj) : error LNK2005: "public: static class boost::chrono::time_point<class boost::chrono::steady_clock,class boost::chrono::duration<__int64,class boost::ratio<1,1000000000> > > __cdecl boost::chrono::steady_clock::now(void)" (?now@steady_clock@chrono@boost@@SA?AV?$time_point@Vsteady_clock@chrono@boost@@V?$duration@_JV?$ratio@$00$0DLJKMKAA@@boost@@@23@@23@XZ) already defined in libboost_chrono-vc141-mt-gd-x32-1_66.lib(chrono.obj) 1>libboost_timer-vc141-mt-gd-x32-1_66.lib(cpu_timer.obj) : error LNK2005: "double __cdecl boost::chrono::chrono_detail::get_nanosecs_per_tic(void)" (?get_nanosecs_per_tic@chrono_detail@chrono@boost@@YANXZ) already defined in libboost_chrono-vc141-mt-gd-x32-1_66.lib(chrono.obj) 1>C:\Projects\aZ80\vs\Debug\aZ80.exe : fatal error LNK1169: one or more multiply defined symbols found Swapping the order of the includes appears to workaround the problem. Mark. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 5

[release] Boost 1.66.0 Release Candidate 1
by Daniel James 11 Dec '17

11 Dec '17

The release candidates for the 1.66.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.66.0/source/> The in progress release notes are: <http://www.boost.org/users/history/in_progress.html> Library documentation is available at: <http://www.boost.org/doc/libs/1_66_0/> The SHA256 checksums are as follows: c9d29486dd12f19d321da65eb5f0a157ec0f0edfd4701ade48c644310c8f0676 boost_1_66_0_rc1.7z 6232f7e7873b2d1f112fb62c726f7066e9a7e0643ed2aac7d31d20bf5749fbc0 boost_1_66_0_rc1.tar.bz2 30ad6d1c7380d6e6a87ce1bc54388ab957de67a2e8fa44dd3c106eafad0f6ac2 boost_1_66_0_rc1.tar.gz cd2c64f243c89e04329e94f3b803f0744171b44fee7a8b4e3256b3a625dcbd1c boost_1_66_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.

5 5

Info: Boost.Config is older than your compiler version - message is surprising
by Paul A. Bristow 11 Dec '17

11 Dec '17

I've just updated to the latest and greatest Visual Studio 15.5 and also got my Boost develop branch up-to-date. But I'm still getting this message: "Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message." I've just rebuilt my library files that have the new -x64- x32 in the name (great - but grrrr because I have had to change all my command files to generate them, previously in /x64 and /win32 folders ;-) The library files have names like libboost_chrono-vc141-mt-x64-1_66.lib so version number is still at 1.66 (a fact confirmed by the config_info Boost version 106600) The config_info.txt output is attached. So I am surprised to get this potentially useful warning. It would *much* more helpful if the warning told which version number of both compiler and Boost? (Just like the 'File not found' message that provokes "Which *&%$%^!!ing file" expletives). Paul PS The Good news is that defining BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE quiets as promised. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

4 15

Help requested for boost documentation for polymorphic_value
by Jonathan Coe 11 Dec '17

11 Dec '17

I have been preparing polymorphic_value for submission to boost. I have draft documentation here: https://drive.google.com/open?id=1xpD8s8zDzedVDDlqjsl1JtYGaJBHWoGy but am having problems generating doxygen docs. A forward declaration seems to stop generation of docs for methods of polymorphic_value. I'm at a loss as to why doxygen is not working properly for boost doc (it works fine when run in isolation) and would be grateful for any insight anyone can offer. I suspect it's a simple problem but I'm not very experienced with doxygen and am new to the boost docs tools. source is here: https://github.com/jbcoe/polymorphic_value/tree/boost regards, Jon

2 2

Optional third-party libraries
by James E. King, III 09 Dec '17

09 Dec '17

The boost documentation on the web site talks about building boost from source, but I don't see information on how to leverage optional third party libraries easily accessible in the documentation from the place the user will most likely end up: "Building From Source". This information seems to be tucked away in documentation of various components, making it difficult to actually build a complete boost. I think it would be a good idea to bring this information up to the top level build instructions, at the very least itemize these third party packages and then link to the relevant project-specific documentation pages that talk about configuring to use them. Here are the third party optional libraries I know about so far and the libraries that use them: bzip2 (iostreams) iconv (locale - if icu not available) icu (locale, regex) lzma (iostreams) openssl (asio, beast) pthread-win32 (sync, thread) zlib (beast, gil, iostreams) Any others? Would folks find it useful if this information was part of the standard "Building From Source" sections of the upper layers of documentation? Thanks, Jim

5 5

[config] msvc-15.5, updating tests
by John Maddock 09 Dec '17

09 Dec '17

While working on updating Boost.Config for msvc-15.5 I've managed to break the test case for boost_no_cxx17_iterator_traits (both GCC and msvc agree on this) but can't see what's wrong :( The change is this one: https://github.com/boostorg/config/commit/305f5a58ef879037b0fd9fdaa8e05615c… which removes use of std::iterator as a base class. Anyone any ideas? Many thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 2

[release] Boost 1.66.0 Beta 1 Release Candidate 1
by Daniel James 09 Dec '17

09 Dec '17

The release candidates for the 1.66.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> The SHA256 checksums are as follows: 0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac boost_1_66_0_b1_rc1.7z eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0 boost_1_66_0_b1_rc1.tar.bz2 f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038 boost_1_66_0_b1_rc1.tar.gz d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798 boost_1_66_0_b1_rc1.zip The in progress release notes are at: <http://www.boost.org/users/history/in_progress.html> And the documentation is at: <http://www.boost.org/doc/libs/1_66_0_beta1/> 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.

11 42

[beast] Security Review: Hybrid Application Assessment
by Vinnie Falco 09 Dec '17

09 Dec '17

Since 2005, Bishop Fox has provided security consulting services to the Fortune 1000, high-tech startups, and financial institutions worldwide. The author of Beast, Vinnie Falco, engaged Bishop Fox to assess the security of the Boost C++ Beast HTTP/S networking library. The following report details the findings identified during the course of the engagement, which started on September 11, 2017. The assessment team conducted a hybrid application assessment of the Beast library. Bishop Fox’s hybrid application assessment methodology leverages the real-world attack techniques of application penetration testing in combination with targeted source code review to thoroughly identify application security vulnerabilities. These full-knowledge assessments begin with automated scans of the deployed application and source code. Next, analyses of the scan results are combined with manual review to thoroughly identify potential application security vulnerabilities. In addition, the team performs a review of the application architecture and business logic to locate any design-level issues. Finally, the team performs manual exploitation and review of these issues to validate the findings. <https://vinniefalco.github.io/BeastAssets/Beast%20-%20Hybrid%20Application%…> Note: The permessage-deflate vulnerability described in the report is confirmed to be fixed in the version of Beast which is included in Boost 1.66.0 Thanks

1 0

Requesting endorsements for YAP review
by Zach Laine 07 Dec '17

07 Dec '17

I mailed the list several months ago about YAP, an expression template library written against C++14 and later standards. The sources can be found here: https://github.com/tzlaine/yap and online docs here: https://tzlaine.github.io/yap I'd like to put this in the review queue, and so I'm looking for endorsements for this. At the time of my initial emails, there was some interest, but not much. Expression templates are a niche technology, so this makes sense. I'm trying to make ETs less expert friendly, so that they leave their experts-only niche. I feel this library does a fairly good job of that. If you do too, please endorse! Thanks, Zach

4 4

Discovering and handling missing override keyword in project conversion
by James E. King, III 06 Dec '17

06 Dec '17

I'm in the middle of converting a large project from C++03 to C++14, and of course crossing the C++11 gap, I want identify all of the places where the override keyword should be used but is not, and add it. When I turned on -Wsuggest-override in gcc-7.2 I got a fair number of warnings from boost code, for example: ...boost/program_options/value_semantic.hpp:304:14: error: â€˜bool boost::program_options::typed_value<T, charT>::is_composing() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] bool is_composing() const { return m_composing; } ^~~~~~~~~~~~ ...boost/program_options/value_semantic.hpp:306:18: error: â€˜unsigned int boost::program_options::typed_value<T, charT>::min_tokens() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] unsigned min_tokens() const ^~~~~~~~~~ ...boost/program_options/value_semantic.hpp:315:18: error: â€˜unsigned int boost::program_options::typed_value<T, charT>::max_tokens() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] unsigned max_tokens() const { ^~~~~~~~~~ ...boost/program_options/value_semantic.hpp:325:14: error: â€˜bool boost::program_options::typed_value<T, charT>::is_required() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] bool is_required() const { return m_required; } ^~~~~~~~~~~ (There were others - this is just a small sample) This is probably not the first time this has been brought up, but there is no BOOST_OVERRIDE (or BOOST_FINAL, for that matter) definition in Boost.Config that would allow Boost itself to be compatible with C++03 or C++11 cleanly relative to this language feature. I found a number of posts about this issue elsewhere. Has this issue been discussed here before? I could spend some time adding this to Boost.Config and then making boost compile cleanly with cxxstd=03,11 toolset=gcc-7 cxxflags="-Wsuggest-override", as it would help support a more complete conversion to the new language level for projects, and it would enable existing projects to turn on the warning to improve their code, as well as improve Boost. Thoughts? - Jim

1 0

[release] 1.66.0 closed for release
by Daniel James 06 Dec '17

06 Dec '17

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out this weekend. You can still modify the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q…> Thanks, -- The Boost Release Team

1 0

Policy for breaking changes
by Louis Dionne 05 Dec '17

05 Dec '17

Hi all, So far, I've been careful about not doing any breaking changes to Hana. Hana obeys semantic versioning, and I'm accumulating desirable breaking changes until I'm ready to publish a new major version. I'm wondering what's the policy for major breaking changes with Boost libraries. For example, let's say I wanted to do an update of Hana with C++17 features; this would be a large breaking change, with all kinds of API changes, etc.. - Are such drastic changes prohibited altogether? Or perhaps they’re not prohibited but there’s historical evidence showing it’s always a bad idea? - Do such changes require going through a mini review? - Is it customary to leave the old version of the library there in a separate directory (or put the new one in a separate directory)? I think Spirit does that, e.g. Spirit Classic is still available IIRC. I think I know the answer to these questions from observing other author's behavior, but I'd like to see what the community thinks about this. It has an impact on the Boost libraries as a whole, since a major breaking change in one library could prevent users from updating Boost as a whole, which has an impact on all of us. I'm looking forward to hearing other people's thoughts on the matter. Thanks, Louis

18 30

[type_index] type names string cross-platformness
by Damien Buhl 05 Dec '17

05 Dec '17

Dear Boost, MSVC differs from GCC & Clang in the way it present the pretty_name of a type_info within Type Index. Indeed for the following type : struct why {}; Is presented as `struct why` while on GCC it is `why`. Is there any reason why pretty_name wouldn't strip / add the information from one of the compiler in order to reach a cross-plaftorm string name of types ? MSVC:http://rextester.com/QNMB58390 <http://rextester.com/QNMB58390> GCC: http://coliru.stacked-crooked.com/a/1aa52003605d4936 Would such a patch to the library be possible & welcome ? Best regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 1

MSVC 15.5 support
by Olaf van der Spek 05 Dec '17

05 Dec '17

Hi, 15.5 Preview has been released: https://blogs.msdn.microsoft.com/vcblog/2017/10/11/productivity-structure-v… > Unknown compiler version - please run the configure tests and report the results How do I do this? Could this message be updated to indicate it comes from Boost? Gr, -- Olaf

4 7

Announcement: Faber, a new build system based on bjam
by Stefan Seefeld 05 Dec '17

05 Dec '17

Hello, about a year ago I started to experiment with a new Python frontend for Boost.Build. After many iterations of prototyping things are starting to fall into place, and the project stabilizes. I'm thus happy to announce the release of Faber version 0.2: code: https://github.com/stefanseefeld/faber docs: https://stefanseefeld.github.io/faber While Faber retains most of the features from Boost.Build, it is redesigned from the ground up. bjam is still used as scheduling engine, but everything else is written in Python. In particular, Jamfiles are replaced by fabscripts, which are essentially Python scripts. The project contains a range of examples to demonstrate various simple use-cases, from a simple "hello world" example to demos involving autoconf-style config checks, and unit testing. I have added build logic to Boost.Python to use Faber on Travis-CI as well as AppVeyor, which also is a good litmus test for Faber's capabilities. I'd be very interested in feedback as well as contributions. Perhaps it might become possible one day to integrate Faber with other efforts to add a Python frontend to Boost.Build. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

13 48

BOOST_PRAGMA_MESSAGE?
by Peter Dimov 04 Dec '17

04 Dec '17

In what module does the following utility macro: #if defined( __GNUC__ ) #define BOOST_PRAGMA_MESSAGE_IMPL_1( x ) _Pragma( #x ) #define BOOST_PRAGMA_MESSAGE( x ) BOOST_PRAGMA_MESSAGE_IMPL_1( message( x ) ) #elif defined( _MSC_VER ) #define BOOST_PRAGMA_MESSAGE_IMPL_2( x, f, ln ) __pragma( message( f "(" #ln "): note: " x ) ) #define BOOST_PRAGMA_MESSAGE_IMPL_1( x, f, ln ) BOOST_PRAGMA_MESSAGE_IMPL_2( x, f, ln ) #define BOOST_PRAGMA_MESSAGE( x ) BOOST_PRAGMA_MESSAGE_IMPL_1( x, __FILE__, __LINE__ ) #else #define BOOST_PRAGMA_MESSAGE( x ) #endif belong? Use: BOOST_PRAGMA_MESSAGE( "something" ) MS output: .\testbed.cpp(10): note: something g++ output: testbed.cpp:10:35: note: #pragma message: something BOOST_PRAGMA_MESSAGE( "something" ) ^

3 10

[accumulators] No maintainer?
by Sergiu Deitsch 04 Dec '17

04 Dec '17

Boost.Accumulators does not seem to have an active maintainer anymore. My PR hast been waiting for any reaction from a maintainer for over a year now. Can someone of the Boost devs take a look at my (pretty trivial) PR at https://github.com/boostorg/accumulators/pull/5 and possibly merge it?

3 2

[hash][array][stacktrace][type_index] Adding noexcept to hash
by Daniel James 04 Dec '17

04 Dec '17

Hi, I want to add noexcept support to the hash library, but a few libraries (array, stacktrace, type_index, maybe more) forward declare hash_range for themselves, causing errors if I add a noexpect specifier to hash_range. If I move hash_fwd.hpp into the core module, so that it doesn't add a dependency on the functional module, would they be okay with including it from there? thanks, Daniel

2 4

Re: [boost] PSA: Travis OS X bottleneck, <cxxstd> new Boost.Build feature
by Robert Ramey 02 Dec '17

02 Dec '17

On 11/29/17 1:10 AM, Boris Kolpackov wrote: > In this light, I think it makes more sense to ask Boost users > who are using Boost on Mac OS to contribute hardware resources > for CI testing. This is the right idea. Let's go the full monte and take it to it's logical conclusion. a) Encourage users to run tests on the libraries they use by making testing more user friendly. b) Create a CMake or CMake-like dashboard where users can more or less automagically post their results to a common database. Presumable boost regression.py does something similar already. c) Create a program to permit display of this giant "data cube" according to the needs of the user/developer. My personal contribution to moving in this direction can be found at https://github.com/robertramey/library_status This permits me to: a) run the serialization test suite with boost build. This is a single button which builds all the libraries that the serialization depends upon, and runs all the tests. b) The results are displayed on a giant cumulative matrix which permits me to see which tests are failing on which platforms. Here is a recent copy of that matrix http://htmlpreview.github.com/?https://github.com/robertramey/library_statu… more information is available here: http://htmlpreview.github.com/?https://github.com/robertramey/library_statu… If this idea were implemented we would have: a) recent tests on all platforms actually being used regardless of how obscure. b) an easily browsable data base of test results. c) less dependency on centralized CI testing resources d) less pressure on boost testers e) more people participating and being a member of the boost community - helping to promote the "Boost Brand (c)" f) Since Appveyor, Travis, regression.py, and individual users would be posting all results to a common database, we'd be decoupling test results presentation from any particular testing platform. g) Should CMake solution every get accepted, it could easily be adjusted to post the the database as well. Boost needs this going back at least a decade. Robert Ramey

1 0

[release] 1.66.0 closing for release on Wednesday
by Daniel James 02 Dec '17

02 Dec '17

There's still a little time for any remaining bug fixes, documentation updates and release notes. Schedule: 6 Dec - Closed for all changes, except by permission of a release manager 9 Dec - Closed for all changes 13 Dec - Boost 1.66.0 release You can edit the release notes here: https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q…

5 13

[contract] move operations and class invariants
by Lorenzo Caminiti 01 Dec '17

01 Dec '17

Hello all, This is not really a question about Boost.Contract, but more a question on how contract programming interacts with C++ move operations. C++ requires that moved-from objects can still be destructed. Because contract programming requires class invariants to hold at destructor entry, it follows that moved-from objects must still satisfy class invariants. That sounds restrictive... and it might force the class invariants to be empty. For example, for vector a class invariant is size() <= capacity(). Should that sill hold after the vector has been moved? That means I can still call size() and capacity() on a moved-from object, which might not be the case. If some sort of moved() function could be called on a moved-from object, the invariants could be programmed as follow to work around this issue: class vector { void invariant() cont { if(!moved()) BOOST_CONTRACT_ASSERT(size() <= capacity()); ... // Only invariants that are truly needed to execute the destructor. } bool moved() const; public: vector(vector&& other) { boost::contract::check c = boost::contract::constructor(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(!moved()); BOOST_CONTRACT_ASSERT(other.moved()); }) ; ... } ... }; I'm not really sure... What do you think? Do you know if this topic "C++ move & class invariants" has already been discussed somewhere? Thanks. --Lorenzo

6 11

Re: [boost] [contract] move operations and class invariants
by Peter Dimov 01 Dec '17

01 Dec '17

Lorenzo Caminiti wrote: > > read() can fail, so you can drop its "valid" precondition and just fail > > when the handle is invalid. > > Calling read() on a moved-from object so violating its is_valid() > precondition is a bug, not a run-time error while reading the file. The > precondition legitimately remains in place to catch bugs, even after it is > noted that read() can fail because of file-system or other run-time > errors. On one hand, you want to have a precondition. On the other, you say that if you have the precondition, the class would be crippled and not very useful: >> 2. How useful is a class like the one above with "crippled" invariants >> and is_valid() preconditions on all its useful public methods like >> read()? The answer seems to be: not very useful. These are contradictory. Either the class that has preconditions is crippled and not very useful, in which case we drop the preconditions as I suggest; or it's useful, in which case we keep them.

1 0