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

[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