- Boost - lists.preview.boost.org

[Outcome] WG21 papers of interest to Boost and Outcome
by Niall Douglas 24 Oct '17

24 Oct '17

This October's mailing has lots and lots of WG21 papers related to Outcome which were strongly influenced by the peer review here in May. Boost members who contributed to the Outcome v1 review in May should please take a bow and accept thanks for spurring so much discussion and debate regarding these potential future C++ features. Thank you. 1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r3.pdf Utility class to represent expected object 2. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r1.pdf C++ Monadic interface 3. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0762r0.pdf Concerns about expected<T, E> from the Boost.Outcome peer review 4. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0779r0.pdf Proposing operator try() (with added native C++ macro functions!) 5. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0786r0.pdf SuccessOrFailure, ValuedOrError and ValuedOrNone types 6. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0824r0.pdf Summary of SG14 discussion on <system_error>: towards exception-less error handling Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[timer][msvc] Universal-Windows advice needed
by Beman Dawes 23 Oct '17

23 Oct '17

Pull request https://github.com/boostorg/timer/pull/3 is a fix for Universal-Windows: "universal-windows: GetProcessTimes is not supported". Does anyone have a clue whether the P/R is correct and the best solution? Is the stated problem a temporary one that Microsoft will likely fix, and will it likely be a permanent limitation? Thanks, --Beman

1 0

[system] Header-only Boost.System by default ?
by Damien Buhl 23 Oct '17

23 Oct '17

Dear Boost, Is there any reason why Boost system couldn't be set to be header only by default ? Defining both macros allows it : - BOOST_SYSTEM_NO_DEPRECATED - BOOST_ERROR_CODE_HEADER_ONLY This ease, speeds up and reduces binary size greatly, that it's sad that non-aware Boost User needs to link to some dll/so/dylib of Boost.System per default. It has been in many releases of Boost, wouldn't it be good to set it to be the default for a next release ? Cheers, -- Damien Buhl Software Developer +33 6 77 43 10 05

10 25

[BoostBook] how to automatically test code examples?
by Hans Dembinski 19 Oct '17

19 Oct '17

Hi everyone, I am using BoostBook to prepare the documentation for the proposed histogram library https://github.com/HDembinski/histogram I have written a good deal of the documentation already, and it compiles fine with bjam (thanks to Klemens who showed me how). It says in the BoostBook documentation http://www.boost.org/doc/libs/1_65_1/doc/html/boostbook.html "The BoostBook format allows testcases to be generated by weaving together program fragments from example programs in the documentation. This capability is integrated with testsuite generation so that example programs are normal tests in BoostBook." That's awesome, I would love to use this feature, but the documentation is not explaining how to actually do that. I found the element "testsuite" which probably does what I want. I went on to scan the Boost repository for this BoostBook element, but couldn't find an example to copy from. Could someone help me out? How do I modify my BoostBook and Jam files to generate tests out of the code examples in the documentation? Best regards, Hans

6 14

[msvc] #warning preprocessor directive
by Beman Dawes 17 Oct '17

17 Oct '17

I find it very irritating that VC++ does not support #warning, and have opened a feature request: https://visualstudio.uservoice.com/forums/121579-visual-studio?query=Add%20… The last time #warning was suggested it was rejected because not enough people voted for it. So please consider upvoting it on the above link. The lack of #warning affects Boost libraries in that developers avoid otherwise useful warnings because of the hassle for using an extension not supported by VC++. --Beman

6 20

Merged #149, "Encode architecture and address model in versioned layout names"
by Peter Dimov 17 Oct '17

17 Oct '17

I've just merged https://github.com/boostorg/boost/pull/149, "Encode architecture and address model in versioned layout names", into the develop branch. Let's see how this goes. Welcome to 2005. :-)

6 10

How to build boost on windows with Clang/LLVM
by degski 17 Oct '17

17 Oct '17

With the latest snapshot builds of clang, thin LTO is supported on Windows. This thin LTO gives very interesting (speed) results. I would therefore like to start to build boost with clang and no longer with msvc. I have msvc 15.4 installed (the latest incarnation). I made a project-config.jam: =============start=============== import option ; using clang : 6.0 : clang++.exe : <cxxflags>-fmacro-backtrace-limit=0 <cxxflags>-Wno-invalid-token-paste <compileflags>-fmsc-version=1911 <linkflags>-fuse-ld=lld <linkflags>-flto=thin ; option.set keep-going : false ; ==============end=============== I call: bjam -a -d+2 cxxflags="-O0" "-sZLIB_SOURCE=%HOME%\zlib-1.2.8" "-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6" variant=debug instruction-set=haswell threading=multi link=static runtime-link=static --prefix=%PREFIX% --build-dir=c:\boost-build address-model=64 architecture=x86 toolset=msvc --without-python --without-mpi --disable-filesystem2 install This does not work. What is the proper way to compile boost on windows using clang++.exe or clang-cl.exe for use with VS2017. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

3 7

Looking for a task to contribute to boost
by vivek pandya 17 Oct '17

17 Oct '17

Hello Boost Developers, I am Vivek. I contribute small patches to LLVM project. I wanted to work for boost open source project to enhance my C++ knowledge. Could someone suggest some project to me? I will be able to complete task suitable for Google Summer of Code with help and guidance form community. Please also suggest required assignments as I am not a frequent user of Boost libraries. Thanks, Vivek

3 2

Recommend dropping test coverage on msvc-7.1 and msvc-8.0
by James E. King, III 16 Oct '17

16 Oct '17

MSVC 7.1 and MSVC 8.0 are currently listed as "tested" in the Boost 1.65.1 release notes however there are a lot of projects that do not seem to support them well, if at all: http://www.boost.org/development/tests/master/developer/issues.html <http://www.boost.org/development/tests/develop/developer/issues.html> It looks like a large number of libraries will no longer build properly against them based on this report. I'm not sure what the procedure is to come to an agreement to drop a compiler in a release, but it looks like we should consider dropping msvc-7.1 and msvc-8.0. These are very old compilers for Windows development. Dropping them would also allow folks to more easily focus on failures in this report to make sure a release is as clean as possible and simplify the test matrix a little bit. Appveyor only supports back to Visual Studio 2010 at this point, so our ability to get pre-commit checks on compilers before msvc-10.0 is solely based on maintainer effort. I suspect this effort is no longer justified based on the age of the compilers. Thanks - Jim

13 31

Bjam broken on windows with VS2017?
by degski 16 Oct '17

16 Oct '17

My lappie has vs2017 installed, latest (15.4) version, from some days ago. I did the following: 1. Put a clean copy of the boost 1.65.1 source in c: root. 2. issue 'bootstrap.bat' in c:\boost_1_65_1\ (ordinary prompt, no vs thingy). This creates a project-config.jam msvc file. 3. Copied (overwrote project-config.jam) the below contents as project-config.jam to c:\boost_1_65_1\ =======start======= import option ; using clang : 6.0 : "C:\\Program Files\\LLVM\\bin\\clang++.exe" : <compileflags>-fmsc-version=1911 <compileflags>-DBOOST_USE_WINAPI_VERSION=0x1000 <compileflags>-DBOOST_USE_WINDOWS_H=1 <compileflags>-D_WIN32_WINNT=0x1000 <compileflags>-DNOMINMAX <ranlib>"C:\\Program Files\\LLVM\\bin\\llvm-ranlib.exe" <archiver>"C:\\Program Files\\LLVM\\bin\\llvm-ar.exe" <linkflags>-fuse-ld=lld <linkflags>-flto=thin ; option.set keep-going : false ; =======end======== 4. issue 'bjam -d0 --clean' The script of that, and the result is below: Microsoft Windows [Version 10.0.15063] (c) 2017 Microsoft Corporation. All rights reserved. C:\Users\User>cd \ C:\>cd boost_1_65_1 C:\boost_1_65_1>bootstrap.bat Building Boost.Build engine Bootstrapping is done. To build, run: .\b2 To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: .\b2 --help - Getting started guide: http://boost.org/more/getting_started/windows.html - Boost.Build documentation: http://www.boost.org/build/doc/html/index.html C:\boost_1_65_1>bjam -d0 --clean 'C:/Program' is not recognized as an internal or external command, operable program or batch file. etc.. etc... the rest is history? Any ideas? degski

2 3

'Fibre safe optimisations' with gcc/clang (non Windows target) and Boost.Context
by james 15 Oct '17

15 Oct '17

I was considering whether I could/should build an actor system on Rust rather than C++, since it would be an interesting exercise for me. And then I found this article: https://www.reddit.com/r/rust/comments/56wgzq/status_of_coroutines/ In particular: > we noticed that the Rust stdlib is actually using TLS (!) to implement exceptions It seems to me that in practice other compilers might use some sort of thread-local hook for exceptions, whether it is TLS or something lower-level that supports TLS. And that the issue is whether the compiler will assume that the address of the TLS (or thread information block etc) is volatile, or can be cached in a stack frame or register across calls. It seems to me that any such caching of an address might cause difficulty, not just in Rust but also other languages. Microsoft's compiler explicitly has a switch for 'fibre safe optimisations' that disables such caching. The worry I have is code like this: void foo() { try { A() } catch (...) {} B(); // Can switch the context to another underlying OS thread try { C() } catch (...) {} } I am concerned that information about exception handling that was acquired for the first try block, might be retained in the frame and reused in the second try block. and the information might be captured in the frame and/or registers that get saved in the context, but in an arbitrary way. I suspect that access to explicit ABI TLS or C++ thread local is also impacted, although it might be easier to avoid. I guess its not a complete show-stopper if we ensure that fibres never migrate between OS threads, but that is somewhat inconvenient. So - is this actually a Rustc specific issue?

1 0

printf official specs or docs, ISO C99, and C++
by James E. King, III 14 Oct '17

14 Oct '17

I found https://svn.boost.org/trac10/ticket/10541 today and my guess is Boost.Format hasn't been updated to support the ISO C99 extensions, or the Microsoft type formats. Before any work is done on this, I'm looking for any official C++ documentation related to printf support requirements. For example the compatibility section in http://www.cplusplus.com/reference/cstdio/printf/ indicates certain language levels have requirements. Thanks, Jim

3 3

[build] Building library with vc++ 64-bit does not find vcvarsall.bat
by Edward Diener 13 Oct '17

13 Oct '17

If I build any library with any version vc++ 64-bit compiler, by using address-model=64, the vcvarsall.bat is looked for at, for example with msvc-14.0, C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/vcvarsall.bat and is not found. Naturally this leads to basic compilation failures. The path for vcvarsall.bat for msvc-14.0 is C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat instead. All versions of vc++ follow this path structure for vcvarsall.bat Building with any version of vc++ 32-bit, by not specifying the address-model, works correctly.

3 4

1.65.1 as modular packages on Conan.io
by Rene Rivera 13 Oct '17

13 Oct '17

Following on with the announcement before CppCon of the 1.64.0 modular packages here we are with more. I'm pleased to announce that the 1.65.1 Boost C++ Libraries are now available individually using the Conan package manager. There's even some improvements for the 1.64.0 package also :-) Find out more from the Bincrafters post here <http://bit.ly/2g6VEpp>[1]. For help using the packages you can bug the Bincrafters team in the #Conan CppLan Slack channel <http://bit.ly/2ykeqC0>[2]. Conan is a C/C++ (and more) package manager that supports an open ended set of build system and tool integrations including: VisualStudio, Xcode, CLion, Ninja, QMake, Premake, and yes even CMake <http://bit.ly/2xzhpbg>[3]. [1] <https://bincrafters.github.io/2017/10/13/Conan-Packages-Boost-1-65-1/> [2] <https://cpplang.now.sh/> [3] <http://docs.conan.io/en/latest/integrations.html> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

1 0

Maintainers: Adding Coverity Scan to your library
by James E. King, III 12 Oct '17

12 Oct '17

I have completed the work necessary to add Coverity Scan to Boost.Uuid and wanted to share the steps involved. This work can be carried into other libraries fairly easily. 1. Go to Coverity Scan: https://scan.coverity.com/ 2. Sign up/in with your Github account. 3. Create a project for your boostorg/library. It will take about 24 hours for them to activate your account so that you can use the results browser. To run a coverity scan manually: 1. Check out your project master (or whatever branch you want to scan). 2. cd into BOOST_ROOT (where "libs/" is located) 3. Run the libs/uuid/covscan.sh script with the following environment variables set: A. COVERITY_SCAN_TOKEN: the project token in coverity scan B. COVERITY_SCAN_NOTIFICATION_EMAIL: your email C. SELF: your library name, for example SELF=uuid for Boost.Uuid 4. You will need to clean up some cruft it leaves behind as the script is designed for Travis CI - just a couple directories starting with "cov" and a tar.xz file. To integrate coverity scans for every pull request or push into master with Travis CI: 1. Make sure you have Travis CI set up properly to build your project. 2. Copy the Coverity Scan stanza from libs/uuid/.travis.yml into your .travis.yml file. Note that the Boost.Uuid travis configuration now uses jobs instead of matrix, as jobs allow for conditions. I would encourage you to convert your .travis.yml to use jobs as well. 3. The next pull request into master, or the next push into master, will trigger a build, and any build for master will run covscan.sh and upload the data. You can add component regular expressions to ignore/omit other boost library errors if you wish. Here are the results for Boost.Uuid. I have not excluded other components yet: https://scan.coverity.com/projects/boostorg-uuid Initially I saw a flurry of "unhandled exception" items which I dismissed as intentional (i.e. I want the test to segfault if an unexpected exception is thrown so that I can debug it), and that will likely be a common practice for test files, but should not be for implementations. I also caution folks against marking something as a false positive. Approach it with the mindset of, "it must be a fault of the library" before jumping to, "it must be a fault in Coverity" and really convince yourself it is not a code issue. Even if you do not have travis integration in your library, running a manual scan will help you improve the quality of your library, so I recommend everyone at least do that much. - Jim

5 5

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

Boost.Format Library Maintenance
by James E. King, III 12 Oct '17

12 Oct '17

Currently the Boost.Format library is being maintained by the CMT. I would like to petition for that responsibility and lighten their case load further. I recently assumed maintenance for Boost.Uuid, and I have added Universal Windows Platform support to Boost.WinAPI and Boost.Predef so that folks will have an easier time making Windows Store compatible apps. I have also been working on a change that will add UWP support to Boost.Random and turn it into a header-only library, and expect to submit that in the next few days. I would like to shore up the CI environment for Boost.Format and groom the backlog in trac and on github, and get all the open issues resolved. Thanks for your consideration, Jim King

3 3

[Build] How to build libboost_lzma?
by degski 12 Oct '17

12 Oct '17

Up till now I have built libboost_zlib and libboost_bzip2 by setting ZLIB_SOURCE and BZIP2_SOURCE variables to their respective source directories on the bjam command-line and the libraries get built without fail. I gather (from the bjam output) their is now support for lzma, which I would like to use. I've tried a similar (did not find a doc) approach with LZMA by feeding "-sLZMA_SOURCE=c:\xz-5.2.3" (from https://tukaani.org/xz/xz-5.2.3.tar.gz) to bjam. This does not work. How do I make bjam build libboost_lzma? Thanks in advance. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 1

Boost Serialization: Serializing large objects
by Adlai Shawareb 12 Oct '17

12 Oct '17

We are trying to text serialize a 700 MB object. We are getting an archive_exception: input stream error. This is on a 32-bit QNX system. * Is there a limit to the size of the object that can be serialized? * Is there anything we can do to fix or work around this? Here is the code we are using: std::stringstream ss_; boost::archive::text_oarchive oa(ss_, boost::archive::no_header); oa << &object; Adlai

4 11

interest in a stateful pointer library?
by Hans Dembinski 11 Oct '17

11 Oct '17

Hi everyone, I wrote a variant of std::unique_ptr, called tagged_ptr, which allows safe read/write access to a customisable number of bits in the pointer variable. You can find the library on github: https://github.com/HDembinski/stateful_pointer You can use those bits to store extra state in the pointer variable at no extra space cost. I did some benchmarks to show that the computational overhead required for the bit manipulation is also negligible. One needs little imagination to find good use for those bits. As a proof of principle, I wrote an STL compatible string class which has the size of const char*, but can store up to 7 ASCII characters (on a 64 bit system) without allocating any memory on the heap (aka small string optimisation). The string class is also included in the library. To make this work, I use one of the bits in the pointer variable to recognise whether the variable should be interpreted as a pointer or as a char array. The Stateful Pointer library is C++11, header-only, and AFAIK platform-independent (in theory, this has not been tested so far). To create pointers which allow one to use a certain number of bits for other purposes, I rely on Boost.Align to allocate aligned memory. How does it work? Aligned memory, as the name implies, does not point to any address in memory, only certain addresses are allowed. For example, a two-byte aligned memory block can only have an even address. Therefore the lowest bit in the address is always zero. Since the bit is guaranteed to be zero, we can use it to store something else and mask it to zero whenever we need to dereference the pointer. I think this is a generally useful class to have in Boost, so is there some interest in polishing it up in a review process? Best regards, Hans

7 18

Master Regression Tests Failing
by Tom Kent 11 Oct '17

11 Oct '17

It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas? Tom notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated" /var/boost/run/boost_root/libs/thread/build/Jamfile.v2:151: in modules.load from module Jamfile</var/boost/run/boost_roo t/libs/thread/build> /var/boost/run/boost_bb/src/build/project.jam:325: in load-jamfile from module project /var/boost/run/boost_bb/src/build/project.jam:64: in load from module project /var/boost/run/boost_bb/src/build/project.jam:89: in load-used-projects from module project /var/boost/run/boost_bb/src/build/project.jam:75: in load from module project /var/boost/run/boost_bb/src/build/project.jam:89: in load-used-projects from module project /var/boost/run/boost_bb/src/build/project.jam:75: in load from module project /var/boost/run/boost_bb/src/build/project.jam:113: in load-parent from module project /var/boost/run/boost_bb/src/build/project.jam:464: in initialize from module project /var/boost/run/boost_bb/src/build/project.jam:306: in load-jamfile from module project /var/boost/run/boost_bb/src/build/project.jam:64: in load from module project /var/boost/run/boost_bb/src/build/project.jam:145: in project.find from module project /var/boost/run/boost_bb/src/build-system.jam:535: in load from module build-system /var/boost/run/boost_bb/src/kernel/modules.jam:295: in import from module modules /var/boost/run/boost_bb/src/kernel/bootstrap.jam:139: in boost-build from module /var/boost/run/boost_regression/boost-build.jam:57: in module scope from module # Searching for "process_jam_log" in "/var/boost/run/boost_regression/stage/bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/var/boost/run/boost_regression_src/regression.py", line 287, in __init__ self.main() File "/var/boost/run/boost_regression_src/regression.py", line 624, in main getattr(self,action_m)() File "/var/boost/run/boost_regression_src/regression.py", line 581, in command_regression self.command_setup() File "/var/boost/run/boost_regression_src/regression.py", line 352, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "/var/boost/run/boost_regression_src/regression.py", line 715, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "/var/boost/run/boost_regression_src/regression.py", line 740, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log" in any of the following locations: /var/boost/run/boost_regression/stage/bin/process_jam_log /var/boost/run/boost_regression/stage/bin

9 19

[ANN] Boost.UI - a new C++ GUI library
by Kolya Kosenko 10 Oct '17

10 Oct '17

Hello, Here is my C++ GUI library based on Boost, it - is cross-platform - uses native system-provided widgets - has STL-like and Boost-like API - compatible with other Boost libraries - supports modern C++11/14/17 features Currently supported modules: - Graphics - Widgets * Command widgets * Data input-output widgets + Date and time pickers + Strings container widgets + Text widgets * Informational widgets + Logging * Containers + Alerts + Notifications + Prompts - Layouts - Events - Audio - Coordinates - Localization - Thread support - Helpers Documentation (and "Hello, World!" application source code): https://kosenko.github.io/boost.ui/ Source code: https://github.com/kosenko/ui Beman's challenge: https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp Re-implemented GUI examples from Bjarne Stroustrup's book: https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp Other examples: https://github.com/kosenko/ui/tree/master/example What do you think? Regards, Kolya Kosenko.

11 21

Boost Trac, random, No-Maintainer?
by James E. King, III 10 Oct '17

10 Oct '17

I filed 3 defects into Boost Trac for Boost.Random based on work I just did on adding CI integration, and the maintainer that Trac assigned to these new items was "No-Maintainer". That seems incorrect? The backlog in trac for random also has "No-Maintainer" assigned to all the items. For folks who like (potential) compiler optimization bugs: https://svn.boost.org/trac10/ticket/13247 - Jim

10 37

Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 10 Oct '17

10 Oct '17

During the formal review of Beast the desire was expressed to have parsing and serialization available independently of Asio. Unfortunately the obstacles to this are the concrete functions and types required for interoperability with the buffer sequence concepts defined in Asio. I have drawn up a solution to this problem which involves creating two brand new libraries. The first new library is called Boost.Buffers, and I described it partially in an earlier list posting. This library will contain copies of just the header files from Asio needed to implement the buffer sequence concepts. A preprocessor switch will allow users of Boost.Buffers to decide whether to use the copies of the headers, or to just include the Asio headers directly: <https://github.com/vinniefalco/buffers/blob/30ef7031ec0909972a720c0cdd8d6c6…> If an author wants to develop a library which uses just the buffer sequence concepts from Asio, then instead of writing: #include <boost/asio/buffer.hpp> they will instead write: #include <boost/buffers/asio.hpp> in header files, and in their build scripts set: #define BOOST_NET_BUFFER_NO_ASIO 1 This way, their tests and example programs will use the copies of the asio headers found in the Boost.Buffers libraries and everything will work. Boost.Asio will not be a dependency. However, if a consumer of that library wants to also use Boost.Asio, they can do so by just not setting the macro in their build scripts (or explicitly setting it to 0). Now that we have a way to write a library that uses Asio buffer concepts without depending on all of Asio, we can move the Beast dynamic buffer implementations and buffer adapters into the Boost.Buffers library. Boost.Buffers will contain these public includes: Boost.Buffers <boost/buffers.hpp> <boost/buffers/asio.hpp> boost::asio::const_buffer boost::asio::const_buffers_1 boost::asio::mutable_buffer boost::asio::mutable_buffers_1 boost::asio::buffer_copy boost::asio::buffer_size boost::asio::buffer_cast boost::asio:is_const_buffer_sequence boost::asio:is_mutable_buffer_sequence <boost/buffers/buffers_adapter.hpp> <boost/buffers/buffers_cat.hpp> <boost/buffers/buffers_prefix.hpp> <boost/buffers/buffers_suffix.hpp> <boost/buffers/buffers_to_string.hpp> <boost/buffers/flat_buffer.hpp> <boost/buffers/flat_static_buffer.hpp> <boost/buffers/multi_buffer.hpp> <boost/buffers/ostream.hpp> <boost/buffers/read_size.hpp> <boost/buffers/static_buffer.hpp> Boost.Buffers would have dependencies on these Boost libraries: Array Assert Config Core Exception Intrusive StaticAssert ThrowException TypeTraits Beast will then be modified to take a dependency on Boost.Buffers to have access to all the buffer adapters and dynamic buffer implementations. Now that we have a new library which offers Asio buffer concepts and Beast's collection of useful dynamic buffers and buffer adapters, we can extract the HTTP parsing and serialization algorithms from Beast to form a new library: Boost.HTTPKit will contain these public includes: Boost.HTTPKit <boost/http/basic_file_body.hpp> <boost/http/basic_dynamic_body.hpp> <boost/http/basic_parser.hpp> <boost/http/buffer_body.hpp> <boost/http/chunk_encode.hpp> <boost/http/dynamic_body.hpp> <boost/http/empty_body.hpp> <boost/http/parse_error.hpp> <boost/http/field.hpp> <boost/http/fields.hpp> <boost/http/message.hpp> <boost/http/parser.hpp> <boost/http/rfc7230.hpp> <boost/http/serializer.hpp> <boost/http/span_body.hpp> <boost/http/status.hpp> <boost/http/string_body.hpp> <boost/http/string_param.hpp> <boost/http/type_traits.hpp> <boost/http/vector_body.hpp> <boost/http/verb.hpp> Boost.HTTPKit would have dependencies on these Boost libraries: Array Assert Config Core Exception Intrusive StaticAssert ThrowException TypeTraits This new library provides serialization and parsing of HTTP/1 messages to and from Asio buffer sequences, without requiring the full Boost.Asio dependency. The library also provides Beast's universal HTTP message container. Beast will be modified to take an additional dependency on Boost.HTTPKit. This solution satisfies long-stated needs of users to have HTTP parsing and serialization without Boost.Asio. However, there is one problem and that is the documentation. All of Beast's documentation related to buffer-oriented parsing and serialization, message containers, Body types, Fields concept, buffer sequences, and dynamic buffers will now be moved into two other libraries. This leaves the Beast documentation objectively worse off for users, as it is impossible to cross-link to other library documentation from inside a Javadoc comment extracted by Doxygen. I would like to hear ideas for how to smooth this out. Questions: How does the community feel about: * Boost.Buffers as a solution to accessing buffer concepts without Asio? * Boost.Buffers offering Beast's buffer sequence adapters and dynamic buffers? * Boost.HTTPKit depending on Boost.Buffers? * Boost.HTTPKit offering serialization and parsing without Asio? Any feedback is appreciated Thanks

3 5

[outcome v2] Proposed second review dates?
by Niall Douglas 10 Oct '17

10 Oct '17

Dear all, Now that the DoubleEnded review has finished, can I poll for preferred dates for a second Outcome review? Options: 1. Friday 1st December until Monday 11th December? 2. Friday 19th January until Monday 29th January? The reason for the delay is that the documentation writers are committed to other stuff until mid-November, plus there is the US Thanksgiving. Other than documentation, the library is ready to go at https://github.com/ned14/boost-outcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 6

[contract] Differential Sandia's regression tests for C++11, C++14, etc.
by Lorenzo Caminiti 09 Oct '17

09 Oct '17

Hello all, On the regression test site: http://www.boost.org/development/tests/develop/developer/contract.html How do I differentiate between the following? Sandia-clang-4.0-c++11 Sandia-clang-4.0-c++14 Sandia-clang-4.0 They all have the same toolset name clang-gnu-4.0.1 but they have different compiler options (C++11, C++14, original C++ standard). My tests are expected to fail only on Sandia-clang-4.0 but not on the first 2... I need different toolset names to selectively mark the failure expected in expected-failure-markup.xml: <mark-unusable> <toolset name="WHAT_SHALL_I_PUT_HERE?"/> <note author="Lorenzo Caminiti"> Most tests use C++11 lambda functions and variadic macros (even if technically the library itself does not require C++11). </note> </mark-unusable> Other toolset using ...~c++11, ...~c++1y prefixes for this, but Sandia does not. Thanks a lot. --Lorenzo

1 0

Need help >> Boost's managed_shared_memory usage in between two processes (C and C++)
by vijay sharma 09 Oct '17

09 Oct '17

Hi, I am having a Design/Implementation issue with Boost managed_shared_memory. Let me describe it: -------------------- Problem ------------------------- I am having two processes (i) Writer (ii) Reader Here Writer is a c++ executable which is using boost to write in shared memory. Code snapshot for writing method: shm_controller.reset(new boost::interprocess::managed_shared_memory( boost::interprocess::open_or_create, shmName, size));void * addr = shm_controller->allocate(size) ; shm_controller ->deallocate(addr); Once I have addr pointer, I am using memcpy to write in SHM. On other hand I am having Reader, which is C executable. They both are communicating via message passing application. I wrote Reader code in such way: Writer is passing address, which is stored in "addr" (from above code snapshot) to Reader. Once reader receive the address and size, I am using memcpy to write SHM data in Reader's local variable. Note1:- (This reader is not using any boost shm API, as it's C application ) Note2:- I validated address is same on Writer and reader (after communication). But reader's memcpy to read shm data is leading crash in my executable (reader). ------------------------------------------------------------- I need help in : 1) Can we use boost::interprocess::managed_shared_memory in C ?? 2) Is there any implementation problem in above section. (can't a reader access shm of writer via pointer) 3) Is there a way to solve this C and C++ limitation like any wrapper implementation etc. Please provide me any kind of help or pointers on this issue, as I am stuck with this and need to resolve it ASAP. Thanks, sharmavijay1991(a)gmail.com

2 3

Appveyor setup for msvc-14.1 toolset
by Edward Diener 09 Oct '17

09 Oct '17

I have added an Appveyor test to some Boost libraries, but if I specify toolset=msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 on the b2 test script command line the run fails when it gets to 14.1, due to not finding 'cl', but succeeds for the others. What is the magical Appveyor incantation to test the latest VC++ ? I would like to avoid the environment/matrix gunk I see in other appveyor.yml files, but if it is the only way to get msvc-14.1 tests with Appveyor I will use it.

3 3

[review] The review period of Boost.DoubleEnded has ended -- thanks to all involved
by Thorsten Ottosen 09 Oct '17

09 Oct '17

Dear users and members of Boost, We are now done with the review of Benedek Thaler's Boost.DoubleEnded library. Many thanks to all those involved in discussions and reviews. It will take me some time to digest all the feedback and get back with the review results. kind regards Thorsten, review manager -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

Boost.Http parser documentation ready (feedback welcome)
by Vinícius dos Santos Oliveira 09 Oct '17

09 Oct '17

Hi, first of all, do not confuse this “Boost.Http” library with the one who was rejected in the Boost review. I've received financing[1] from Boost to write an HTTP parser and here it is, just a parser. The documentation has 4 tutorials. You may have special interest in the “tutorial #4: implementing Boost.Beast parser interface” where I answer why you don't want to use Boost.Beast parser. https://vinipsmaker.github.io/asiohttpserver/ Feedback welcome. [1] https://gist.github.com/vinipsmaker/4998ccfacb971a0dc1bd -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

1 0

GITHUB - How does one add another maintainer to a repo
by Robert Ramey 08 Oct '17

08 Oct '17

I'm maintainer of the boost serialization library. Is there a simple way to give update permission to other persons? What is it. Ideally I'd like to do it at the branch level. I've looked through the GitHub help, and as usual, I'm mistified. Robert Ramey

2 2

[thread][build] develop terminally broken?
by John Maddock 07 Oct '17

07 Oct '17

All CI tests are currently failing with: ./b2 headers /home/travis/build/boostorg/boost-root/tools/build/src/build/feature.jam:140: in feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "win32" "pthread" : "optional" "propagated" /home/travis/build/boostorg/boost-root/libs/thread/build/threadapi.jam:4: in load from module threadapi /home/travis/build/boostorg/boost-root/tools/build/src/kernel/modules.jam:295: in modules.import from module modules /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:1069: in import from module Jamfile</home/travis/build/boostorg/boost-root/libs/thread/build> libs/thread/build/Jamfile.v2:39: in modules.load from module Jamfile</home/travis/build/boostorg/boost-root/libs/thread/build> /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:325: in load-jamfile from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:64: in load from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:89: in load-used-projects from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:75: in load from module project /home/travis/build/boostorg/boost-root/tools/build/src/build/project.jam:145: in project.find from module project /home/travis/build/boostorg/boost-root/tools/build/src/build-system.jam:535: in load from module build-system /home/travis/build/boostorg/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/travis/build/boostorg/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /home/travis/build/boostorg/boost-root/boost-build.jam:17: in module scope from module Any ideas? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

4 5

[contract] auto_..._error regression tests fail on C++1z
by Lorenzo Caminiti 04 Oct '17

04 Oct '17

Hello all, I asked this question on compl.c++ list as well, given this is more of a general C++1z question than a Boost question. However, this is making some Boost.Contract regression tests fail on C++1z compilers so I wanted to ask it here as well hoping to get some info more quickly... Following code prevents copies outside its friend function f: // File: 05.cpp struct x { x() {} private: x(x const&) {} x& operator=(x const&) { return *this; } friend x f(); }; x f() { return x(); } int main() { auto xx = f(); return 0; } Correctly it does not compile up to C++1y because main cannot access the copy operations: $ clang++ -std=c++1y 05.cpp 05.cpp:14:15: error: calling a private constructor of class 'x' auto xx = f(); ^ 05.cpp:5:5: note: declared private here x(x const&) {} ^ 1 error generated. However, it compiles on C++1z?! $ clang++ -std=c++1z 05.cpp # Not compiler errors?! Why... what changed in C++1z that makes the above compile? How can I prevent copying x outside its friend function f in C++1z? Thanks, --Lorenzo

6 7

[outcome v2] How important is it that an Expected implementation is also provided?
by Niall Douglas 04 Oct '17

04 Oct '17

Dear list, I know it's been a fair few months since any news on Outcome v2. Ordinarily I'd be speaking at CppCon happening right now, but I instead chose Jens' Meeting C++ in November where I'll be speaking on Expected. Outcome v2 has undergone its period of maturation since it was completely rewritten to reflect peer review feedback last May. The new consensus design has fared very well after being put under heavy production use these last few months, and I expect it to return here for a second review before the end of this year. Outcome v2 will also be appearing in the WG21 October mailing, watch out for: * P0762R0: Concerns about `expected<T, E>` from the Boost.Outcome peer review * P0779R0: Proposing `operator try()` Outcome v2 currently implements the not published yet D0323R3 Expected proposal as part of its test suite as a refinement of what boost-dev thought Expected ought to be instead of what it is (ahem!). We run it against the Expected reference test suite, and it passes. So here's the question before any second peer review. Should Outcome v2 provide: 1. No Expected implementation at all, not even under a different name. Not its place. 2. The Expected implementation which the consensus on boost-dev felt the WG21 Expected ought to be (this is the current situation, and no we don't call it `expected<T, E>`). 3. A closely conforming, but not exactly conforming [1], implementation of WG21 Expected. Options 2 and 3 can be combined. But be aware that Peter rolled together an even more conforming Expected implementation using his variant2 library. I had been assuming people would be better advised to use his likely exactly conforming implementation, rather than Outcome v2's not exactly conforming implementation. Less surprise. Thoughts? Niall [1]: Known differences from P0323R3 `expected<T, E>` in this implementation: - `T` and `E` cannot be the same type. - No variant storage is implemented (note that technically speaking, D0323R3 does not require variant storage). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 5

Boost CMake update
by paul 04 Oct '17

04 Oct '17

Hi all, So I have been working at converting more of boost tests to cmake utilizing the BCM library, here: https://github.com/boost-cmake/boost/tree/1.64 This is a build of Boost 1.64, with a majority of the tests integrated. There is still much more work needed to update the tests, as there are some that still fail. Also, some of the libraries were skipped due to missing headers in the 1.64 tag. You can check the library yourself by running cmake: cd build mkdir build cmake .. cmake --build . --target check This will build all the tests. You can check the tests for one target with: cmake --build . --target check-boost_core Which will run the tests for just `boost_core`. This was all generated using scripts in https://github.com/pfultz2/boost-cmake I plan to update this to a newer version of boost. If anyone has fixes or changes they can send a PR or issue on either repos, and I will try to incorporate them in. Thanks, Paul .

8 35

[beast] Supporting ICY 200 OK
by Vinnie Falco 04 Oct '17

04 Oct '17

Bjorn brought up the point that there are some niche cases where applications do not strictly follow the HTTP message syntax for responses. Specifically, for Shoutcast(?) / Icecast mp3 servers the status-line in the response looks something like this: ICY 200 OK\r\n I have thought about ways to support this directly in Beast but I have decided against it. "ICY 200" is not HTTP according to the RFC, and trying to accommodate this use case places needless technical debt in public interfaces. However, I came up with a very simple technique to make this work with Beast by writing just a tiny bit of extra code. The solution is to implement a stream wrapper which meets the requirements of SyncReadStream[1] and/or AsyncReadStream[2] and forwards the calls to read to the "next layer" object, which will be the actual socket or ssl::stream. The implementation of the icy_stream wrapper can check to see if the first 3 bytes received from the next layer match "ICY" and if so, return a buffer to the caller which replaces those characters with "HTTP/1.1" (or "HTTP/1.0"). With this wrapper, calls to beast::http::read or beast::http::async_read can parse the custom response as a regular HTTP message. The wrapper can embed state information to inform the caller if the "ICY" string was not received. The declaration for such a wrapper might look like this: template<class NextLayer> class icy_stream; Usage for the wrapper: asio::ip::tcp::socket sock{ios}; icy_stream<asio::ip::tcp::socket&> stream{sock}; beast::http::response<beast::http::empty_body> res; beast::multi_buffer buffer; beast::http::read(stream, buffer, res); This technique may of course be generalized to support any desired similar but non-standard HTTP requests or responses in a fashion that is completely transparent to Beast. Thanks [1] <http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/SyncRead…> [2] <http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/AsyncRea…>

2 4

Re: [boost] [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!
by Vinnie Falco 04 Oct '17

04 Oct '17

On Tue, Oct 3, 2017 at 9:40 AM, Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > My preview of Boost.Asio version 1.66.0 is here: > > <https://github.com/vinniefalco/boost.asio/commits/net-ts> Upon re-reading the message I realize that it might be confusing, so to clarify - this is NOT an "official" version of Boost.Asio it is just an experimental branch of what Boost.Asio might look like soon, for anyone who wants to try out the latest stand-alone Asio features in the Boost.Asio context. Thanks

2 5

Boost.Buffers, a new library from the makers of Beast!
by Vinnie Falco 03 Oct '17

03 Oct '17

During the formal review of Beast, desires were expressed to use components like the HTTP parser and serializer independently from the rest of the library. The sticking point was the abstraction used to represent a range of non-owning buffers. In particular, Asio imposes certain concrete type requirements in its ConstBufferSequence and MutableBufferSequence concepts. It would seem there is significant interest in making some components of Beast modular, in their own libraries. The main feature of these components would be that they should not require Boost.Asio. Unfortunately, the way Asio's concepts are defined this is not possible. Two solutions present themselves: 1. Create a new buffer sequence concept which retains all the features of Asio's concepts but does not require the concrete types. While this is possible it would create a significant complication. Interfaces which use the new concept would require some kind of adapter at every call site that tries to use a traditional Asio style interface. 2. Create a new library which uses conditional compilation to either include just the Asio header files which fulfill the needs for interacting with buffer sequence concepts, or provide the declarations directly from a copy of the Asio sources. The solution used in Boost.Buffers (a new library I am considering proposing) is choice number two. Someone who wants to create a new library ("Foo") that does no network I/O but wants to interoperate with Asio buffer concepts merely need to do the following #include <boost/buffers.asio.hpp> and then, in their build script for the tests and examples, set: #define BOOST_NET_BUFFER_NO_ASIO 1 This works because Boost.Buffers contains copies of all the necessary header files to work with buffer sequences, and JUST those header files. All of Boost.Asio is not necessary: <https://github.com/vinniefalco/buffers/blob/30ef7031ec0909972a720c0cdd8d6c6…> Now if someone wants to use library Foo they will also be getting a dependency on Boost.Buffers. If that user doesn't need Asio, then they will also set the macro to 1 in their build script. However. if that user wants to use Asio in their program or library, they just set #define BOOST_NET_BUFFER_NO_ASIO 0 and now Boost.Buffers will simply include the relevant Asio header files. This library will allow the creation of new libraries which use Asio buffer concepts, but do not require all of Boost.Asio as a dependency, as well as all the things that Boost.Asio is dependent on, which is non-trivial as can be seen here: <https://github.com/boostorg/beast/blob/develop/.travis.yml#L140> I would like feedback on this library before I move forward with it, as you can imagine it has some controversial aspects to it. Boost.Buffers is here: <https://github.com/vinniefalco/buffers> Thanks

1 0

[beast] The Networking-TS version of Boost.Asio and Boost.Beast is here!
by Vinnie Falco 03 Oct '17

03 Oct '17

I have taken the tip of standalone Asio, from: <https://github.com/chriskohlhoff/asio/commits/asio-1-10-branch> and applied this "boostify.pl" script: <https://github.com/chriskohlhoff/asio/blob/asio-1-10-branch/asio/boostify.pl> plus a bit of manual fixing, to produce a new branch of Boost.Asio which is up-to-date with respect to the stand-alone Asio. This means you can have access to the Networking-TS changes that will be introduced in Boost.Asio (according to the author, this will be in Boost 1.66.0). My preview of Boost.Asio version 1.66.0 is here: <https://github.com/vinniefalco/boost.asio/commits/net-ts> Beast has been ported to this version of Asio, you can try it here: <https://github.com/vinniefalco/beast/commits/net-ts> When Boost.Asio is updated for 1.66.0 to bring it in-line with the standalone Asio (which supports Networking-TS), Beast will simultaneously be updated. Hopefully this will all be done in time for 1.66.0, so that users of the debut version of Beast will have the latest interfaces available for their use. Thanks!

1 0

Modularizing explicit-failures-markup.xml
by Daniel James 03 Oct '17

03 Oct '17

Hi, I'm looking into implementing a mechanism for updating explicit-failures-markup.xml without updating the super project. My basic idea is that modules can have a 'status/explicit-failures-markup.xml' file, and I'll write a script to update the super project file from modules. It will have the same format as the super project file, so can just copy and paste the relevant parts into your module. Does that sound okay? It might be better if the regression scripts handled this themselves, but I'm not sure if anyone would be available to implement that. Daniel

6 12

[asio] Verify SSL certificates using the OS-specific certificate store
by Vinnie Falco 01 Oct '17

01 Oct '17

My understanding of boost::asio::ssl::context is that it is just a small wrapper around OpenSSL. You can set default verify paths, but that assumes the certificates are in a particular directory which they almost never are. For example they might be in some OS-specific type of database which need system calls to access. If a program wants to use the native operating system facilities for verifying certificates, then I believe significant additional code is needed. Is this correct? I am interested in writing a simple function object which will validate a hostname and its accompanying certificate against the operating-system-dependent certificate authorities. Is there some code somewhere that does this? Any resources that I can be pointed to would be of immense value. Thanks

2 1

Re: [boost] [beast] Supporting ICY 200 OK
by Bjorn Reese 01 Oct '17

01 Oct '17

On 10/02/2017 12:06 AM, Vinnie Falco wrote: > However, I came up with a very simple technique to make this work with > Beast by writing just a tiny bit of extra code. The solution is to > implement a stream wrapper which meets the requirements of > SyncReadStream[1] and/or AsyncReadStream[2] and forwards the calls to > read to the "next layer" object, which will be the actual socket or > ssl::stream. Sounds like a good solution.

1 0

[review] The review period of Boost.DoubleEnded has been extended with one week. Now ends 7th of October.
by Thorsten Ottosen 28 Sep '17

28 Sep '17

Dear users and members of Boost, People have been requesting extra time for the review of Boost.DoubleEnded. We therefore continue one week extra, so the final date will be October the 7th. kind regards Thorsten Original review announcement ------------------------------------------ I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Boost.DoubleEnded as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

[admin] Turning on Issues tab on Github for Boost libraries
by Edward Diener 28 Sep '17

28 Sep '17

Can we not have some resolution from an administrator about turning on the Issues tab in Github for Boost libraries ? There are two 'admin' issues regarding this and, since it should be a quick job for an administrator to implement this, I would really prefer not to wait for a long time for this to get done. Just now I had a "bogus" PR for iostreams, which I rejected, and the explanation from the person who created the PR was that the PR was "created" because there was no Issue tab for the library and he was only trying to create an Issue to be looked at. There is absolutely no logical reason that I can think of why the Issue tab on Github cannot be turned on for Boost libraries, to benefit end-users.

3 3

Re: [boost] [ANN] Boost.UI - a new C++ GUI library
by Kolya Kosenko 28 Sep '17

28 Sep '17

On 09/28/2017 03:02 PM, Stefan Seefeld via Boost wrote: >> - uses native system-provided widgets > > what widgets do you consider "system-provided" ? What backends do you > bind to on the different platforms, and can those bindings be changed ? Native system-provided widgets means widgets from toolkits GTK+, Qt, Windows Controls, Cocoa etc. >> - compatible with other Boost libraries > > What does that mean ? Boost.Geometry and Boost.Polygon could be used with Boost.UI coordinates, Boost.Chrono - boost::ui::on_timeout() function, Boost.Date_Time library are used in date and time pickers etc. > I'd be interested in some high-level documentation explaining the basic > programming and execution model of the API. You can ask for implementation details here. Documentation explains only API. > For example, how are events > handled and how are they bound to particular actions ? Library subscribes to event handlers in native toolkit. When user press button, native event handler eventually calls Boost.UI event handler. > Are programs > inherently multi-threaded or single-threaded (e.g., does the main event > loop run in its own thread) ? There is main GUI thread and you should call GUI functions from other your own threads using boost::ui::call_async() function. Boost.UI library (like all other C++ GUI libraries) aren't thread safe because native toolkits are not thread safe. > Is your library mostly just a (thin) layer over existing > platform-specific GUI libraries, or does it reimplement a lot of the > logic itself ? Boost.UI is a rather thin layer with C++11/Boost support. > (And what is that cryptic "ui_main()" function ? :-) ) ui_main() function call required for GUI initialization, deinitialization, cleanup. It is required for underlying toolkits. Actually you can call some functions directly from main() function, but it is at your own risk. Regards, Kolya.

2 4

[1.65] [process] Library version outdated
by Andrey Semashev 28 Sep '17

28 Sep '17

Hi, It looks like something is broken in the release procedure, which resulted in all Boost 1.64.0, 1.65.0 and 1.65.1 to contain the same revision of Boost.Process 4075371cbe78dab8f43578c655747c831b554318 (you can see that by git tags). This revision is dated Wed Apr 5 11:32:27 2017, which is more like when 1.64.0 was being prepared. I know that 1.65 has long sailed, but can the release managers double check that this doesn't happen in 1.66? As a possible clue, on the local checkout I didn't have a head for the master branch for Boost.Process for some reason. I surely wasn't doing anythhing special with its repository, but maybe something happened on the remote side that caused this. I solved the problem locally by removing libs/process, .git/modules/process and running `git submodule update --init --recursive`.

3 3

[Pool] no maintainer, and should perhaps be deprecated?
by John Maddock 27 Sep '17

27 Sep '17

Moving this conversation to a new thread: >As an example of this: I recently proposed to add variadic move >construction for nodes to boost::pool (a trivial change). And even though >this has obvious advantages (and would get rid for C++11 capable compilers >of the use of M4 to generate the necessary code), this was received with: >file a PR, including tests (?) and change to documentation. Enough to put >me off, so I just changed it locally. Unfortunately the pool lib is not a good example - as previously stated it has no current maintainer - but as (probably) the last person to try and do some community maintenance on this library, the impression I came away with was that it needs rewriting. Actually more than that.... it probably needs redesigning if many more of the existing bug reports are to be fixed. I've actually said this on the list before, and suggested that Pool.2 might be a good candidate for as someone's first Boost library (since it's not too large), but so far no takers. There is possibly another issue: the performance of most std lib allocators has improved to the point that it's actually questionable whether using the pool lib has much real benefit (but this need quantifying so the cases where it does help are documented). Maybe that's what has put people off, or maybe it's just not sexy enough for anyone to take on, but I still hope that someone will.... Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 1

[multi_index] Taking advantage of C++17 auto template params to simplify key specification
by Joaquin M López Muñoz 27 Sep '17

27 Sep '17

Consider the following: struct element { int x; int f()const{return x;} }; int gf(const element& e){return e.x;} using container=multi_index_container< element, indexed_by< ordered_unique<member<element,int,&element::x>>, ordered_unique<const_mem_fun<element,int,&element::f>>, ordered_unique<global_fun<const element&,int,&gf>> > >; With the advent in C++17 of auto non-type template parameters, it is very easy to provide a boost::multi_index::key class template so that we can write: using container=multi_index_container< element, indexed_by< ordered_unique<key<&element::x>>, ordered_unique<key<&element::f>>, ordered_unique<key<&gf>> > >; (Example at http://coliru.stacked-crooked.com/a/5742c768cc093c03 ). Is there interest in adding this to Boost.MultiIndex? Comments on this or alternative syntaxes? Thank you, Joaquín M López Muñoz

5 9

Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
by Fletcher, John P 27 Sep '17

27 Sep '17

________________________________________ From: Thorsten Ottosen [tottosen(a)dezide.com] Sent: 26 September 2017 08:28 To: Fletcher, John P Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30 >> Hi Fletcher, >> >> On another topic, I have not seen in the documentation any discussion of models for what is going on. I am aware of Chris Okasaki's book "Purely Function Data Structures" (1998) and a lot of subsequent literature. Does this work relate at all to previous work? >I'm not familiar with that book. You should think of standard C++ >containers like std::vector and std::deque which models a sequence concept: I should have given a reference. Here is one. http://okasaki.blogspot.co.uk/2008/02/ten-years-of-purely-functional-data.h… This is the authors comments on 10 years from publication. If you put the title into google you will get lots of information. My point is that there is a strong theoretical basis in this area and one of the issues for me is how far this has been taken into account in this new work. I was not until recently familiar with the work. It has helped me a lot understand the underlying problems in this area and I want to know whether the author of the library has looked at it. There is nothing in the documentation that I have seen about the wider issues. John Fletcher

2 1

Please fix executable permissions on header files
by Jonathan Wakely 25 Sep '17

25 Sep '17

The following files have executable permission bits set, which causes warnings for me when packaging Boost for Fedora (and is just wrong, because they're not executables): $ find boost_1_65_1/boost -name '*.hpp' -perm /111 boost_1_65_1/boost/numeric/conversion/detail/old_numeric_cast.hpp boost_1_65_1/boost/python/converter/arg_to_python.hpp boost_1_65_1/boost/python/converter/context_result_converter.hpp boost_1_65_1/boost/python/converter/pytype_function.hpp boost_1_65_1/boost/python/converter/return_from_python.hpp boost_1_65_1/boost/python/detail/convertible.hpp boost_1_65_1/boost/python/detail/copy_ctor_mutates_rhs.hpp boost_1_65_1/boost/python/detail/def_helper_fwd.hpp boost_1_65_1/boost/python/detail/is_shared_ptr.hpp boost_1_65_1/boost/python/detail/is_wrapper.hpp boost_1_65_1/boost/python/detail/nullary_function_adaptor.hpp boost_1_65_1/boost/python/detail/prefix.hpp boost_1_65_1/boost/python/detail/python_type.hpp boost_1_65_1/boost/python/detail/sfinae.hpp boost_1_65_1/boost/python/detail/unwind_type.hpp boost_1_65_1/boost/python/detail/unwrap_type_id.hpp boost_1_65_1/boost/python/detail/unwrap_wrapper.hpp boost_1_65_1/boost/python/detail/value_arg.hpp boost_1_65_1/boost/python/object/function_doc_signature.hpp boost_1_65_1/boost/python/object/inheritance_query.hpp boost_1_65_1/boost/python/object/stl_iterator_core.hpp boost_1_65_1/boost/python/arg_from_python.hpp boost_1_65_1/boost/python/base_type_traits.hpp boost_1_65_1/boost/python/borrowed.hpp boost_1_65_1/boost/python/cast.hpp boost_1_65_1/boost/python/def_visitor.hpp boost_1_65_1/boost/python/docstring_options.hpp boost_1_65_1/boost/python/handle_fwd.hpp boost_1_65_1/boost/python/object.hpp boost_1_65_1/boost/python/object_protocol_core.hpp boost_1_65_1/boost/python/raw_function.hpp boost_1_65_1/boost/python/refcount.hpp boost_1_65_1/boost/python/self.hpp boost_1_65_1/boost/python/stl_iterator.hpp boost_1_65_1/boost/python/wrapper.hpp boost_1_65_1/boost/interprocess/detail/managed_memory_impl.hpp boost_1_65_1/boost/interprocess/detail/managed_multi_shared_memory.hpp boost_1_65_1/boost/interprocess/detail/managed_open_or_create_impl.hpp boost_1_65_1/boost/interprocess/detail/shared_dir_helpers.hpp boost_1_65_1/boost/bimap/container_adaptor/unordered_associative_container_adaptor.hpp boost_1_65_1/boost/parameter/aux_/preprocessor/flatten.hpp boost_1_65_1/boost/parameter/aux_/preprocessor/for_each.hpp boost_1_65_1/boost/parameter/aux_/python/invoker_iterate.hpp boost_1_65_1/boost/parameter/aux_/overloads.hpp boost_1_65_1/boost/parameter/aux_/parameter_requirements.hpp boost_1_65_1/boost/parameter/aux_/result_of0.hpp boost_1_65_1/boost/parameter/aux_/tag.hpp boost_1_65_1/boost/parameter/aux_/template_keyword.hpp boost_1_65_1/boost/parameter/aux_/void.hpp boost_1_65_1/boost/parameter/aux_/yesno.hpp boost_1_65_1/boost/parameter/match.hpp boost_1_65_1/boost/parameter/parameters.hpp boost_1_65_1/boost/parameter/python.hpp boost_1_65_1/boost/parameter.hpp boost_1_65_1/boost/ptr_container/detail/default_deleter.hpp boost_1_65_1/boost/ptr_container/detail/is_convertible.hpp boost_1_65_1/boost/ptr_container/detail/move.hpp boost_1_65_1/boost/ptr_container/detail/scoped_deleter.hpp boost_1_65_1/boost/ptr_container/detail/throw_exception.hpp boost_1_65_1/boost/ptr_container/detail/void_ptr_iterator.hpp boost_1_65_1/boost/ptr_container/exception.hpp boost_1_65_1/boost/ptr_container/nullable.hpp boost_1_65_1/boost/thread/concurrent_queues/queue_base.hpp boost_1_65_1/boost/thread/experimental/parallel/v2/task_region.hpp boost_1_65_1/boost/thread/v2/shared_mutex.hpp boost_1_65_1/boost/iostreams/detail/adapter/device_adapter.hpp boost_1_65_1/boost/iostreams/detail/adapter/filter_adapter.hpp boost_1_65_1/boost/iostreams/detail/adapter/non_blocking_adapter.hpp boost_1_65_1/boost/iostreams/detail/broken_overload_resolution/forward.hpp boost_1_65_1/boost/iostreams/detail/config/enable_warnings.hpp boost_1_65_1/boost/iostreams/detail/config/limits.hpp boost_1_65_1/boost/iostreams/detail/config/windows_posix.hpp boost_1_65_1/boost/iostreams/detail/absolute_path.hpp boost_1_65_1/boost/iostreams/detail/bool_trait_def.hpp boost_1_65_1/boost/iostreams/detail/counted_array.hpp boost_1_65_1/boost/iostreams/detail/template_params.hpp boost_1_65_1/boost/iostreams/restrict.hpp boost_1_65_1/boost/msm/mpl_graph/mpl_graph.hpp boost_1_65_1/boost/typeof/dmc/typeof_impl.hpp boost_1_65_1/boost/typeof/std/bitset.hpp boost_1_65_1/boost/typeof/std/complex.hpp boost_1_65_1/boost/typeof/std/deque.hpp boost_1_65_1/boost/typeof/std/fstream.hpp boost_1_65_1/boost/typeof/std/functional.hpp boost_1_65_1/boost/typeof/std/iostream.hpp boost_1_65_1/boost/typeof/std/istream.hpp boost_1_65_1/boost/typeof/std/iterator.hpp boost_1_65_1/boost/typeof/std/list.hpp boost_1_65_1/boost/typeof/std/locale.hpp boost_1_65_1/boost/typeof/std/map.hpp boost_1_65_1/boost/typeof/std/memory.hpp boost_1_65_1/boost/typeof/std/ostream.hpp boost_1_65_1/boost/typeof/std/queue.hpp boost_1_65_1/boost/typeof/std/set.hpp boost_1_65_1/boost/typeof/std/sstream.hpp boost_1_65_1/boost/typeof/std/stack.hpp boost_1_65_1/boost/typeof/std/streambuf.hpp boost_1_65_1/boost/typeof/std/string.hpp boost_1_65_1/boost/typeof/std/utility.hpp boost_1_65_1/boost/typeof/std/valarray.hpp boost_1_65_1/boost/typeof/std/vector.hpp boost_1_65_1/boost/typeof/encode_decode.hpp boost_1_65_1/boost/typeof/encode_decode_params.hpp boost_1_65_1/boost/typeof/incr_registration_group.hpp boost_1_65_1/boost/typeof/int_encoding.hpp boost_1_65_1/boost/typeof/integral_template_param.hpp boost_1_65_1/boost/typeof/modifiers.hpp boost_1_65_1/boost/typeof/pointers_data_members.hpp boost_1_65_1/boost/typeof/register_mem_functions.hpp boost_1_65_1/boost/typeof/template_encoding.hpp boost_1_65_1/boost/typeof/template_template_param.hpp boost_1_65_1/boost/typeof/type_encoding.hpp boost_1_65_1/boost/typeof/type_template_param.hpp boost_1_65_1/boost/typeof/typeof_impl.hpp boost_1_65_1/boost/typeof/vector.hpp boost_1_65_1/boost/typeof/vector100.hpp boost_1_65_1/boost/typeof/vector150.hpp boost_1_65_1/boost/typeof/vector200.hpp boost_1_65_1/boost/typeof/vector50.hpp

5 7

request git repository for boost.contract
by Lorenzo Caminiti 25 Sep '17

25 Sep '17

Hello all, I need some help... who should I ask to create a git repository "contract" for boost.contract? How do I link that to the main boost repository in git? Please send me link if this info is already documented somewhere. Thank you. --Lorenzo

2 2

[review][Fit] Fit Review Results
by Matt Calabrese 25 Sep '17

25 Sep '17

Hello everyone, It is my privilege to announce that the Boost library count will once again be incremented as Paul Fultz II's library Fit has been accepted into Boost without conditions. Further details about this decision follow, but before that I'd like to thank Paul for all of the hard work he has put into Fit. Thanks also to everyone who participated in the review, with additional thanks to Vicente who was the review manager for the previous Fit review and who also provided a very detailed review and discussion during this review period. //////////////////////////////////////////////////////////////////////////////// Overview //////////////////////////////////////////////////////////////////////////////// Complete Reviews Considered: Zach Laine: Accept Vicente J. Botet Escriba: Accept John P. Fletcher: Accept Robert Ramey: Accept Jason Rice: Accept Barrett Adair: Accept Lee Clagett: Accept Glen Fernandes: Accept Louis Dionne: Accept Partial Reviews/Discussions Considered: Edward Diener Andrea Bocci Further Discussions (Previous Review): Steven Watanabe Peter Dimov Vladimir Batov Gavin Lambert Rob Stewart Bjorn Reese Manu Sanchez Artyom Beilis //////////////////////////////////////////////////////////////////////////////// Summary //////////////////////////////////////////////////////////////////////////////// Though not all responders reviewed every single aspect of the library, the reviews together adequately covered everything that is necessary for a decision to be made. This decision is made with additional confidence coming from usage of the library by some reviewers going back since during or before the initial review in early 2016. //////////////////////////////////////////////////////////////////////////////// Improvements Since Previous Review //////////////////////////////////////////////////////////////////////////////// This time around we received several more complete reviews than in the previous review period making it easier to be confident in a decision. A couple of notable changes since the 2016 review include: * Improved documentation * Default semantics for "capture" no longer try to determine whether to capture by reference or by value based on the argument being an lvalue or an rvalue (users can still get this via basic_capture) * Improved ADL awareness (internal calls are qualified) Throughout all of the discussions in this second review period, there were no explicit rejections of the library as a whole, though there were several recommendations from participants. A selection of those are listed here, though no changes are strictly required for acceptance: //////////////////////////////////////////////////////////////////////////////// Current Concerns //////////////////////////////////////////////////////////////////////////////// ////////// Design concerns: * Inheritance from user-callables has some potential pitfalls * Generated "infix" operators are "gimmicky" and don't add much value/may cause confusion * Placeholders should live in their own namespace ////////// Documentation concerns (not a complete list): * More examples requested * It is not always clear what files need to be #included for certain facilities in early examples * Better rationale for ConstFunctionObjects * Raw code is not linked from the examples ////////// Suggested name changes from reviewers: * Suggested rename of "partial()" to "partial_apply()" or "curry()" * Suggested rename of "conditional()" to "invoke_first()" or "call_first_of()" * Suggested rename of "apply" to "invoke" * Refer to "Callables" instead as "Invocables" (due to C++17 direction) * Library name "Fit" is not indicative of what it provides //////////////////////////////////////////////////////////////////////////////// Regarding the Author //////////////////////////////////////////////////////////////////////////////// Paul has been active in the Boost community for several years now. He is aware of his responsibilities going forward and I am confident that he will be a reliable maintainer for Fit for the foreseeable future (or whatever the library may be called). //////////////////////////////////////////////////////////////////////////////// Comments on the Name Boost.Fit //////////////////////////////////////////////////////////////////////////////// Note that what I say here is my personal opinion as a member of the community and does not necessarily reflect the opinions of others in the community nor of those in the steering committee. A few reviewers voiced that they would like to see a change of the library name "Fit". While multiple people did suggest this, my opinion is that this should be up to the author to choose whether or not he will change the name before it is added to boost and so I do not think it would be appropriate for us to strictly require or encourage such a change. If the author found the arguments against the name compelling, then he is welcome to change the name, but he should not feel obligated to do so. As a quick note on that, we have several high quality and highly regarded libraries in Boost with names that may not directly tell users what the library is for. Based on their popularity, I do not believe that it has significantly negatively affected their usage or ability to be found. A library name also may be important to an author as a creative outlet and I think it would be... poor form us to force such a change in this particular case and in other cases unless there are very strong reasons (i.e. the name is overly or intentionally misleading or there are legal concerns). I am not convinced that the current name is misleading enough to strictly require a change. As for existing precedent, some examples of libraries already in Boost with names that do not directly tell the user what the library is for include some of Boost's most highly regarded libraries such as Boost.Spirit (including Qi and Karma), Boost.Phoenix, Boost.Wave, Boost.Hana, and the recently accepted Boost.Beast. //////////////////////////////////////////////////////////////////////////////// Thanks again to everyone who participated in this review and in the previous review, and once again, congratulations to Paul on his library's acceptance into Boost. -- -Matt Calabrese

4 3

[utility] [config] value_init tests on msvc-14.0, 14.1
by Peter Dimov 24 Sep '17

24 Sep '17

Currently, value_init_workaround_test.cpp fails on both msvc-14.0 and 14.1, because in: #ifdef BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED // One or more failures are expected. return num_failures > 0 ? EXIT_SUCCESS : EXIT_FAILURE; #else // No failures are expected. return num_failures == 0 ? EXIT_SUCCESS : EXIT_FAILURE; #endif failures are supposedly expected (BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED is defined), but there are none. BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED is controlled by BOOST_NO_COMPLETE_VALUE_INITIALIZATION, which is defined on 14.0/14.1. The Config macro is defined because - presumably - msvc 14.0/14.1 fail the Config test for value initialization, boost_no_com_value_init.ipp. But this test is much more comprehensive than the value_init one. So to fix the value_init_workaround_test.cpp failure, we need to at minimum move one failing test case from the Config test to the value_init one.

2 3

Modular Packages on Conan.io
by Rene Rivera 24 Sep '17

24 Sep '17

One of the most requested feature from Boost users is having a "modular" distribution. I'm happy to announce that there are now modular packages available when using the Conan package manager from the Bincrafters team < http://bit.ly/2wM5AdT>[1]. Using the packages requires no prior setup other than the Conan tool. Immediately available are all 130 libraries from the 1.64.0 release. And in a few days we will follow up with the same for the 1.65.1 release. For help using the packages you can bug the Bincrafters team <http://bit.ly/2xWEGEX>[3] in the #conan cpplang.slack.com channel < http://bit.ly/2hnMB3o>[4]. Conan is a C/C++ (and more) package manager that supports an open ended set of build system and tool integrations including: VisualStudio, Xcode, CLion, Ninja, QMake, Premake, and yes even CMake <http://bit.ly/2xzhpbg>[2]. [1] <https://bincrafters.github.io/2017/09/22/boost-modular-packages-conan/> [2] <http://docs.conan.io/en/latest/integrations.html> [3] <https://bintray.com/bincrafters/public-conan> [4] <https://cpplang.slack.com/messages/C41CWV9HA> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

Including open source, non-copyright, no warranty in a boost library
by James E. King, III 24 Sep '17

24 Sep '17

Hello, I'm working on refactoring boost::uuids::name_generator to have a configurable hash algorithm through a template concept. RFC 4122 allows for two hashing algorithms, MD5 and SHA1. The current implementation only does SHA1, however I want to add MD5 for completeness (and I want to prepare for the eventual successor to SHA1 in the next RFC for UUID). I found an open source MD5 implementation of RFC 1321 at the following location and I was wondering if there are rules against bringing it into boost as a detail implementation? http://openwall.info/wiki/people/solar/software/public-domain-source-code/m… Thanks, Jim

4 3

BCM - Boost CMake Modules request for endorsement
by paul 22 Sep '17

22 Sep '17

Hi, So the Daniel Pfeifer has agreed to be the review manager for the Boost Cmake Modules. I would like ask for an endorsement so we can schedule a formal review for BCM. Thanks, Paul .

5 7

Travis/Appveyor improvements for the superproject
by Peter Dimov 22 Sep '17

22 Sep '17

Travis and Appveyor tests for the Boost superproject have been improved to automatically run the tests for the library mentioned in the commit message. For example, if the message is "Update iterator from develop", the corresponding CI job runs the tests of the Iterator library (among other things). This is a bit redundant if the library itself has Travis/Appveyor set up, but keeping an eye on https://ci.appveyor.com/project/boostorg/boost/history and https://travis-ci.org/boostorg/boost/builds can't hurt. For example, Appveyor says that Iterator fails a test on msvc-12.0 (Visual Studio 2013): https://ci.appveyor.com/project/boostorg/boost/build/1.0.3744-develop and Utility fails a test on msvc-14.0/msvc-14.1: https://ci.appveyor.com/project/boostorg/boost/build/1.0.3765-develop

9 16

[review][Fit] Review of Fit starts today : September 8 - September 17
by Matt Calabrese 22 Sep '17

22 Sep '17

A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Anyone who is able to provide an assessment of the design, implementation, and/or docs can participate in this review. Usage experience is not absolutely necessary to give feedback, but is highly recommended if you are writing a review. Discussions about aspects of the library are welcome even if a complete review is not presented, though participants are asked to please state whether they would like to accept or reject the library before the deadline of September 17, paying close attention to the questions raised at the end of this email. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. We will be grateful to receive a review based on whatever level of effort or time you can devote. This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed. The following is a brief description of the library from its author: ==================== Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming. Fit is: Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: Function Adaptors and Decorators: These enhance functions with additional capability. Functions: These return functions that achieve a specific purpose. Utilities: These are general utilities that are useful when defining or using functions. Requirements This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported. Contexpr support: Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs. Noexcept support: On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this. ==================== Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! -- -Matt Calabrese

13 39

Crypto/hashes library?
by James E. King, III 21 Sep '17

21 Sep '17

Hello, The boost uuid module contains an implementation of the sha1 hash algorithm for purposes of generating a uuid from arbitrary input. I've opened an issue on github to make the hash algorithm configurable: https://github.com/boostorg/uuid/issues/26 I was hoping to find a concept and implementation of a few hashes somewhere in boost that could be used instead, however I haven't found any. Back in 2010 someone posted a link to a "boost::hashes" repository but I was unable to see what the outcome of the discussion was other than that it was not included. A collection of hashing algorithms that are well tested would be quite useful in a number of ways; and I like the hash size template style used in the repo from 2010: https://svn.boost.org/svn/boost/sandbox/hash/ Indeed there's mention of a discussion about the proper placement of sha1 inside boost::uuid in there: https://svn.boost.org/svn/boost/sandbox/hash/libs/hash/doc/html/rationale.h… So I was curious where that effort ended up, and if there was a resolution on whether an independent library for hashing was ultimately something that folks wanted to pursue or avoid. Thanks, Jim

8 16

[move] [container] workaround for incorrect [-Wignored-attributes]
by Groke, Paul 21 Sep '17

21 Sep '17

Hi, we've stumbled over a supposed bug in GCC 6 that generates incorrect [-Wignored-attributes] warnings. Using anything in Boost that relies on boost::move_detail::aligned_storage (like boost::container::small_vector), with a small enough type, will trigger this warning when compiling for certain architectures with at least GCC 6.2~6.4. Affected architectures are e.g. SPARC and ARM - not affected are x86 and ARM64. GCC bug ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82270 It would be possible to work around this issue by changing the implementation of boost::move_detail::aligned_storage_impl so that the aligned type no longer carries the attribute(aligned) itself, but just contains a member which carries that attribute. If I understand this correctly this should have the same effect (barring compiler bugs). Question: Would a pull request for such a change be welcome? Regards, Paul Groke

2 1

Mini review of the Fit library
by Glen Fernandes 21 Sep '17

21 Sep '17

What follows is my mini review of the Fit library. I had no time to write a full review, but feel that most of my points have been covered by others in both the first and this second review. A. Should the library be accepted into Boost? Yes; I vote to accept Fit - with no conditions for acceptance. B. What is your evaluation of the design? I found it: 1. Practical: For facilities like BOOST_FIT_LIFT. 2. Innovative: For facilities like infix(). And overall useful. C. What is your evaluation of the implementation? Good. Appears to be correct C++ code, and is definitely written in a very maintainable way. Ordinarily I'm in favor of not seeing macros used for what is accomplished by FIT_INHERIT_DEFAULT, FIT_INHERIT_CONSTRUCTOR, and similar, but this is a minor thing, and it does serve to make the code smaller and easier to review. I also like that the lowest version of C++ standard support required is C++11 (and not higher), as I am still aware of a large enough pre-C++14 user base that do have access to and use Boost libraries. D. What is your evaluation of the documentation? Excellent. Better than what I generally write. Useful enough for me, and in my opinion, sufficient for understanding the library and learning how to use it - for any user that takes the time to read through it all. E. What is your evaluation of the potential usefulness of the library? I believe it to be useful, and I know of at one developer that I have suggested Fit to, that has started using it - and another that would like to start using it if it is included in a Boost release (for which their organization has blanket approval to use). F. Did you try to use the library? With which compiler(s)? Did you have any problems? Not recently, but Yes. With g++ 6.3. I encountered no problems. G. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I had spent at least 3+ hours looking into Fit with the intention of reviewing it for my own use, and learning how one part of it was implemented. I did not have a chance to spend as much time as I would normally have to write a full review of the library. H. Are you knowledgeable about the problem domain? Familiar with enough functional programming design and generic programming to appreciate the library. Other notes: No concern about the name. We have Beast, Hana, Spirit; Fit is a fine enough name, and boost::fit:: is a convenient enough prefix. Glen

2 1

docs to release a new lib
by Lorenzo Caminiti 21 Sep '17

21 Sep '17

Hello all, Where are the latest docs to add a new lib to Boost (including regression tests, PDF docs, etc.)? Poking around a bit I found the following links... https://svn.boost.org/trac10/wiki/StartModMaint https://svn.boost.org/trac10/wiki/DeveloperChecklist I'm asking because I'm considering adding Boost.Contract to the Boost 1.66.0 release. Thanks a lot! --Lorenzo

1 0

[review] Final Notice! Fit Review Ends Today!
by Matt Calabrese 20 Sep '17

20 Sep '17

Hi everyone, The formal review of the Fit library is ending today, September 20th. For anyone who was waiting until the last minute to submit a review, this would be it. Anything that you can provide is helpful in making a decision, even if you do not write a complete review of the entire library. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! -- -Matt Calabrese

1 0

Re: [boost] [review][Fit] Review of Fit starts today
by Jason Rice 19 Sep '17

19 Sep '17

Please consider this review for the proposed Boost.Fit library. I recommend the review manager ACCEPT this library for inclusion in Boost without condition. # What is your evaluation of the design? - Making high order functions easier and more concise is a good idea. - I like the point-free programming features. - Some of the names, conventions, and errors would take any kind of user some getting used to. - A version of `alias_value` that works in a generic context where the type might not be an alias would be more useful I think. # What is your evaluation of the implementation? - The code is consistent across implementations and the files are pretty flat - Each function can be included independently which is nice. - It appears that there is some effort towards making errors easier to read. For instance, I called `fit::partial` with too many arguments and the error was "error: no member named 'fit_function_param_limit'" - There is some readability issues due to compiler compatibility support and specific compiler error workarounds. - I noticed `fit::decay` is not used in the tests at all. It gets included in `example.h` but is never used. # What is your evaluation of the documentation? - I like that the documentation is easy to read in the comments of each file. - Some of the wording in the descriptions weren't very helpful for me personally, but the "Semantics" section seemed to always get the point of the function across. # What is your evaluation of the potential usefulness of the library? - It seems parts of the library might not be that useful if you have constexpr lambdas, but I believe there are still features that enable more concise coding even against latest C++17 features. - I will probably use this library now that I am familiar with it. # Did you try to use the library? With which compiler(s)? Did you have any problems? - I made a couple of my own examples. - I used a fairly recent fork of clang trunk with c++1z. - BOOST_FIT_RETURNS *crashed the compiler* when I was trying to construct an std::array with some pack expansion. It looked like it crashed the parser. # How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - I spent a couple of hours looking at the docs in the source and making my own test programs to see how it could be used. # Are you knowledgeable about the problem domain? - I've used Boost.Hana a lot with its "functional" features. - I've done a lot of point free programming with RamdaJS in Javascript # Were the concerns from the March 2016 review of Fit addressed? N/A For what it's worth here is a link to some of my attempts to sample the library: https://gist.github.com/ricejasonf/9bfd233b3bc282eae9ecb8bc3198d948 Thank You, Jason Rice

2 1

[Container] small flat set ?
by Phil Endecott 18 Sep '17

18 Sep '17

Dear all, boost::container::small_vector and boost::container::static_vector are great. boost::container::flat_set is great too. But today I need a small_flat_set! And I don't think it's possible to compose flat_set and small_vector. (flat_set can use a custom allocator, but it can't take a custom implementation type in the way that, for example, std::priority_queue can.) Having said that, maybe composing flat_set and small_vector (or static_vector) isn't the optimum solution for the case where I will store something like 0...4 ints; I suspect that linear search in an unordered sequence will be quicker. But that gets complicated if you need iterators with the normal behaviour. Any thoughts? Regards, Phil.

5 14

Last Day for Boost Community Dinner Sign up
by Jon Kalb 18 Sep '17

18 Sep '17

Boost Developers, Today is the last day to register for the Boost Community Dinner at CppCon. http://sched.co/Bhcr You do not need to be registered to attend CppCon to register for the Boost Community Dinner: https://cppcon.org/registration/ If you are going to be in the Seattle area a week from Tuesday, join us for a rare face-to-face get together of the Boost Community. See you there. Jon

1 0

[docs] Documentation on Github?
by John Maddock 18 Sep '17

18 Sep '17

I notice that a few libraries are serving their documentation pages on github, for example http://boostorg.github.io/quickbook/doc/html/index.html How is this being done? Thanks! John. --- This email has been checked for viruses by AVG. http://www.avg.com

8 8

[review] Reminder that Fit Review Is Ending Soon. Please review!
by Matt Calabrese 16 Sep '17

16 Sep '17

Hi everyone, The formal review of the Fit library was scheduled to end tomorrow, September 17. At this point we do not have very many reviews and so we are extending the review period until the 20th. Anyone who can is encouraged to participate. Anything that you can provide is helpful in making a decision, even if you do not write a complete review of the entire library. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! - Matt Calabrese

1 0

[winapi] Enable Travis and AppVeyor
by Andrey Semashev 16 Sep '17

16 Sep '17

Hi, I'm trying to enable Travis and AppVeyor builds for Boost.WinAPI, and Travis says that I need admin rights on the project to do it: https://travis-ci.org/boostorg/winapi I don't know if AppVeyor also needs admin rights, maybe someone with more experience could clarify. Could I have the admin rights for Boost.WinAPI? Or maybe boostorg admins could do the necessary steps to enable the project in Travis and AppVeyor? Thanks.

2 7

Searching for Review Manager for reflection library without macro
by Antony Polukhin 15 Sep '17

15 Sep '17

Hello, PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Anyone wishing to become a Review Manager for the library? Boost libraries that may benefit from PFR: * Convert - for out-of-the-box conversions of user types * Hana - for using user types instead of tuples * Intrusive - for reusing unused bits in user provided types * Serialization - for out-of-the-box serialization of user types * Spirit - for putting rule results into user provided types without Phoenix or Fusion macro * Test - for outputting content of user provided types * TypeTraits - for traits like has_unique_object_representations in C++14 -- Best regards, Antony Polukhin

7 9

boost::random, header-only, boost::uuids::detail::seed_rng, and UWP development
by James E. King, III 14 Sep '17

14 Sep '17

Hi folks, It looks like the only reason boostorg/random is not a header-only library is due to random_device (it is the only src/ file: https://github.com/boostorg/random/tree/develop/src) The older WinCrypt calls are not available in some Windows platforms going forward, so this is going to become a problem pretty quickly for the community. In the boostorg/uuid library there is a seed_rng class which is doing similar things (however providing more entropy) and the library is header-only. In addition there are two filed defects - one in Trac and one in github issues, about uuid being incompatible with UWP applications (that's Windows universal apps). In uuid, I started adding support for BCrypt which is a Windows API supported on later versions of Windows, and once I changed my build flags to target Windows 10 and WINAPI_FAMILY_APP, I started getting build failures in random_device. On further inspection it looks like the random library doesn't have support for BCrypt yet, and even worse as a source library one would need to build two variants - one for WinCrypt and one for BCrypt to support older and newer windows platforms. There are also some implications on MinGW, as the older original MinGW has support for WinCrypt and MinGW-64 supports both. I'm going to propose that the implementation from boost::uuids::detail::seed_rng be moved into boost::random as the new random_device implementation. At the same time, boost::random will become header-only, and thus support setting _WIN32_WINNT at build time of consuming applications properly, and therefore support new Windows platforms properly. At the same time I would like to change seed_rng such that it no longer silently ignores some return values, and does not disable any compiler warnings (deprecations, currently). Thoughts? Thanks, - Jim

6 15

C++17 detection
by Robert Ramey 14 Sep '17

14 Sep '17

How do I get ready for C++17? I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have #if C++14 being used namespace std { // implement C++ function } // std I've looked in the documentation for Boost.Config and can't find any hints there. What is the best way to do this? Robert Ramey

14 25

[review queue] we seem to have double allocated early September for review --- what to do?
by Thorsten Ottosen 12 Sep '17

12 Sep '17

Hi All, I was about to announce the start of the Boost.Double_ended review, running from today to 17th of September. This is what we agreed upon with John (Phillips). Now, when I look at http://www.boost.org/community/review_schedule.html it seems that there is also a review of the Fit library scheduled, greatly overlapping with Boost.Double_ended. Do we run two reviews simultaneously, or what? kind regards Thorsten

5 12

Re: [boost] Review Request: impl_ptr (pimpl)
by Vladimir Batov 11 Sep '17

11 Sep '17

On 2017-08-19 23:55, Mario Lang wrote: > Vladimir Batov via Boost <boost(a)lists.boost.org> writes: > ... > I got interested enough by this posting so that I ended up doing my own > mini-review just right now :-). And I just wanted to let you know (and > encourage you) that I like this one alot. Keeping the public interface > free of boilerplate is quite nice! Mario, Thank you for your input. Much appreciated... although somewhat early. :-) It was pointed out to me that Boost review procedures changed and a proposal has to be endorsed before it can move to the review stage. So far I do not see it happening... maybe because the list is quiet (overall), maybe because iml_ptr is not good enough to attract that support/endorsement, maybe giving "endorsement" puts too much pressure and people shy away from it. We'll see. > I think for a full boost review, you will probably need to work on: > * The documentation > While I gave it a read, I ended up skipping to your test case because > I wanted to see working example code. > While the current docs have quite some examples, they spend a lot > more > screen space with showing what impl_ptr tries to replace, without > showing a good motivating positive example of how it actually looks > when employed. It also feels like it is spending some time with > marketing speak, while not really showing what it is trying to sell: Yes, I hear you... and I (at least partially) agree with you. First, no code or documentation will ever be to everyone's liking... unless everyone writes their own. Secondly, the documentation reflects many discussions we've had on this list about pimpl. For ex., I had to explicitly add what you call "marketing speak" to plainly explain why IMO pimpl is important. I had to address numerous "why bother" dismissing comments. What you call "marketing speak" I call an architectural view of a project. IMO it's quite different from developer's view that you seem to favor. All views are important... and all of them IMO need to be mentioned to cater for and to convince different readers. Surely, you (as a developer) is free to skip the "marketing speak". Somebody else (an architect and code-reviewer) might decide to skip other bits. No drama. Does it make sense? > The separation between the public interface in a hpp and the template > specialization in a cpp. I think the motivating example should > clearly show what part of the code goes where. Isn't what I did in third and fourth chapters? That said, I'll never be able to write the way you (or somebody else) like it. So, if you feel really strongly about it, please feel free to re-write it as you feel proper and submit. I am more than happy to consider and take others help. Unfortunately, that'll reverse our positions as I (and potential reviewers) might be saying "nuh, not enough "marketing speak" and such. No pressure... but that's an option to shape it up to your liking. > * Namespace: > While the alias is good, I think the whole code should be moved to > boost::, and the detail to boost::detail::impl_ptr::. > I am sort of guessing this will come up in the review. > I might be interested to help with that and submit the renaming PR if > you are open to that. 1) I do agree that the "whole code should be moved to boost::"... when it is part of Boost. Currently it is not. Currently I am on the earliest stage of gathering interest and waiting for "endorsement" and the review manager. 2) As I think I mentioned before impl_ptr is not part of any namespace by design... because the way proxy and implementation are connected, the specialization of impl_ptr<>::implementation. As I also mentioned it is IMO only a "problem" for "purists" but not for "practitioners" as from outside it is all kosher and accessed via boost::impl_ptr. You might be interested in searching for "Pimpl Again?" thread on this list for prev. discussions. Still, it you know a way around it and willing to submit your suggestions, I am certainly open for and most welcome it. But just to state the obvious -- as you do not like every line of code/doc that I write -- that goes both ways.

5 14

[beast] Post-review follow up (RE: chunk-encoding) NEEDS YOU!
by Vinnie Falco 11 Sep '17

11 Sep '17

During the formal review for Beast, a valid point was raised that the facilities for interacting with the chunks which make up a chunk-encoded was insufficient for some use-cases. I added more interfaces to addresses the use-cases but I never got feedback from the stakeholders about the design. It is now September 10th, and the "pencils down" deadline for making changes to Beast ahead of the 1.66.0 scheduled release is October 25th. As I have not gotten any feedback, I am asking the community if there is anyone out there who would like to review the new chunk-encoding facilities. As of yet, no one in the wild has used them. Or if they have, I did not hear of it. This is the documentation for the chunking: <http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_http/c…> Repository: <https://github.com/boostorg/beast> Any feedback is appreciated. Thanks

1 0

Fit review - viboes
by Vicente J. Botet Escriba 10 Sep '17

10 Sep '17

Hi, here it is my review. I believe that Boost.Fit should be*accepted*. *Design* The design is sound and clean. I have some concerns respect the the ConstFunctionObjects that I believe should merit an explanation on a rationale section. Why the library support only Const function objects? Wondering if some parts should be moved to Boost.TypeTraits or reused from there (is_callable). I'm missing the std::invoke function. The_adaptor<> are not documented. The utility of those classes is not documented. If the user can use those classes the documentaion must document them. I guess they are useful to build other adaptors. It is not clear whether the defined functions would use SFINAE or just fail when used with types that don't respect the requirements. While I'm generally for SFINAE, I understand that it will not be the case in order to improve the compile time. It is not clear if the functions can be final function objects or not. *Implementation* Not seen in depth. It should use as much as possible Boost.Config and/or Boost.Predef Possible files contains details that could be shared in Boost or used from other Boost libraries https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/move.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/noexcept… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/and.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compress… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/constexp… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/intrinsi… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/pp.hpp https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/remove_r… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/result_o… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/static_c… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/using.hpp It uses a lot of macros that make complex the understanding of what is behind. On the same file https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/compose.hpp and only on 169 lines BOOST_FIT_INHERIT_CONSTRUCTOR, BOOST_FIT_RETURNS_CLASS, BOOST_FIT_SFINAE_RESULT, BOOST_FIT_MANGLE_CAST, BOOST_FIT_DECLARE_STATIC_VAR, BOOST_FIT_NOEXCEPT_CONSTRUCTIBLE, BOOST_FIT_ENABLE_IF_CONSTRUCTIBLE, BOOST_FIT_JOIN *Documentation* Quite good butthe description of the semantic of the provided functions would need some extra wording. Maybe a section that states that the semantic expression is part of the constraints on the types. It takes too much pages to see what the library proposes. For some functions we would need more information, examples. See below the detailed *Potential usefulness of the library* Very useful. *Did you try to use the library? With which compiler(s)? Did you have any problems?*** Not tried yet. *How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?*** In-depth study of the documentation (about 5 h for this revision). *Are you knowledgeable about the problem domain?* In general, yes. *Were the concerns from the March 2016 review of Fit addressed?*** I believe ;-) Best, Vicente *Documentation:* In general: * Navigation only from the top of the page * Hyper links missing. * There is no link to real code from the examples. In particular: *http://pfultz2.github.io/Fit/doc/html/doc/src/gettingstarted.html* An explanation of the BOOST_FIT_LIFT limitations would be more than welcome. Typo: last right parenthesis in // Pipable sum BOOST_FIT_STATIC_LAMBDA_FUNCTION(sum) = pipable([](auto x, auto y) { return x + y; }); It is not clear if the following is correct in the body of a function autosum = pipable([](auto x, auto y) { return x + y; }; *http://pfultz2.github.io/Fit/doc/html/doc/src/example_print.html* I would suggest to use an heterogeneous tuple in the for_each_tupleexample. In addition use some kind of brackets to print the sequences and the tuples would help to identify what is been printed. *http://pfultz2.github.io/Fit/doc/html/doc/src/example_overloading.html* Typo: Before // Check that T has member function for operator* and ope After // Check that T has member function for operator* and opeerator-> I'm not sure the example is_derreferenceable is fair. *http://pfultz2.github.io/Fit/doc/html/doc/src/example_polymorphic_constructors.html* Maybe it is worth adding references to the proposals (P0318R0 and P0338R2) *http://pfultz2.github.io/Fit/doc/html/doc/src/more_examples.html* Extension Methods It is not clear what numbers, filter and transform are in the example. I believe that the range proposal woul include the pipe operator. My question is how both pipe operator overloads interact. http://pfultz2.github.io/Fit/doc/html/doc/src/point_free.html typo Before |b(f)(x, y)| |after| ||by(f)(x, y)|| *http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html* It woul dbe great to have an example associated to each definition Static Function Adaptor I would say "It has an additional requirement that the *class****function* is |DefaultConstructible|:" Decorator I would say "The *resulting* Function Adaptor <http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html#function-ada…> may be an unspecified or private type." Typo? Some parts of the documentation provides *http://pfultz2.github.io/Fit/doc/html/doc/src/concepts.html* ConstFunctionObject I would like to note that this concept is not representable using the Concept TS as it is quantifying universally on the Ts (args) parameters. The same applies to UnaryFunctionObject, BinaryFunctionObject Wondering if the documentation should use the term Concepts then. The use of expresion "Is an object with ..." is confusing. What are we qualifying the type or the instance? Maybe it is worth defining FunctionObject. EvaluatableFunctionObject It is not clear why this kind of FunctionObjects is useful Callable I believe we have moved to call this Invocable in the standard. But again, I believe that you want to quantify universally the arguments, isn't it? Does your definition of INVOKE differs from the one on the standard? If yes, the differences should be mentioned. If not, the definition on the standard should be referenced. You use type T twice with different meaning "The type |T| satisfies |Callable| if" "if |f| is a pointer to member function of class |T|:" I believe that here the T are not the same. Are final function objects Callable, ConstCallable? ConstCallable The brief description is the same as the one for Callable Is the definition of the second INVOKE different from the first one? UnaryCallable The name doesn't convey that it is *Const*Callable Metafunction and MetafunctionClass it is not clear what those are, there is no brief description. I guess that this applies to f. What do you mean by a type or a template? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/by.html* It is not clear to me what by(p)(xs...) == p(xs)... mean An example of `fit::by` without a function argument will be welcome. It is not clear how by_adaptor<Projection, F> and by_adaptor<Projection> can be used by the user? Shouldn't those be hidden? This is a genral remak, why F must be ConstCallable? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/compose.html *The requirements don't state clearly the constraints on the input parameters of f and the result of g, except by the semantic expression. This is a general remark. I suspect that you mean the semantic expression must be well formed. But, is this SFINAE friendly or is this a requirement? Can both function be final function objects? **** *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/conditional.html* It is not clear what king of parameters this function could have (in particular in comparison with P0051). Does it accept function/data members pointers, final classes, references_wrappers, ...? Typo "Proposal for C++ Proposal for" P0051 original proposal uses overload_linearly/overload (as Boost.Hana) instead of conditional/match. Wondering if those names aren't more clear. Why do we need to change the Boost.Hana names? There is also std::conditional :( Can more than 2 parameters be final function objects? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/flip.html** * IIUC, F must not be BinaryCallable, but Callable with at least two arguments. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/implicit.html* Is implicit a StaticFunctionAdaptor? Shouldn't StaticFunctionAdaptors have Functions as parameters? I named the `auto_cast` function `explicitly` to do a explicit conversion. Other uses of this pattern I've see are to create a buffer able to store a specific struct struct S; S* ptr = create_msg(); create_msg returns an class that is convertible to a T* and that allocates sizeof(T) bytes of memory. Why this pattern respect the DRY principle (we don't repeat S), I believe it abuses of implicit conversions. Anyway, I wanted just to share another use case for implicit. http://pfultz2.github.io/Fit/doc/html/include/boost/fit/indirect.html Wondering if it could be worth adding some preconditions as I guess that the function call indirect(f)(xs...) will be undefined if f is null *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/infix.html** * One of the asked infix operations is pow. However we would like to evaluate from right to left and have the higher precedence than * x pow ypow z===pow(x, pow(y,z)) x * ypow z===x * pow(y,z) x pow y* z===pow(x,y) * zWith the proposed infix notation this should be written x <pow> (y<pow> z)===x * pow(y,z) x * (y<pow> z)===x * pow(y,z) (x <pow> y)* z===pow(x,y) * z and the following would be surprising x <pow> y<pow> z===pow(pow(x, y, z) x * y<pow> z===pow(x * y, z) x <pow> y*z===pow(x, y * z) It would work better for swap or compare (proposed operator <=>) as these functions are not associative. I believe a note should prevent the users for such bad use cases, for which it is better to don't define the infix operator. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lazy.html* Note p0356r1. It would be good to have a comparison in order either to improve the proposal or your library. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/match.html* Same comments than for fit::conditional. What are ex typo "Proposal for C++ Proposal for" Can more than 2 parameters be final function objects? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/mutable.html *Example of bad usage would be welcome.**Why Fit uses always const? **Why not use a reference to the function object instead? Is there a safe way to use MutableFunctionObjects with Fit? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/partial.html* Are there any constraints on the type of xs. Shouldn't them be MoveConstructibles? http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pipable.html Are there any constraints on the type of x. Shouldn't it be MoveConstructible? http://pfultz2.github.io/Fit/doc/html/include/boost/fit/protect.html It is not clear to me what this useful for. Could you elaborate? Is there a typo here assert(lazy(f)(protect(lazy(g)(_1)))() == f(lazy(g)(_1))) ^ Shouldn't it be assert(lazy(f)(protect(lazy(g)),_1)() == f(lazy(g)(_1))) *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/result.html*** This adaptor converts explicitly the result of the call to the type. Have you considered `convert_to`? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html* as_failures, with_failures, .... /adaptors/ don't appear on the index. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reverse_fold.html* reverse_fold is not right fold, as right fold is right associative, isn't it? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/rotate.html*** Could you show a concrete use case? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/static.html*** What are the differences of this adaptor and the macro STATIC_FUNCTION? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack.html* Why name it unpack instead of apply like in C++17? Need to introduce the Sequence concept and how it is customized? unpack_sequence? How unpack_sequence is used by unpack? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack_sequence.html*** Why unpack_sequence, and not the tuple-like traits? Is unpack_sequence defined if the class defines the tuple-like traits? Aside the example, it is not defined what the user must define. What the member function apply must return? How the unpack_sequence parameter and the Sequence parameter of member function apply are related? I don't understand template<class F, class Sequence> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS ( s(std::forward<F>(f)) ); Is a Sequence a callable taking a Callable or there is a type here? Is there a missing return? I suspect it should be template<class F, class Sequence> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS ( std::forward<F>(f)(s0, ,, sk); ); If this is correct, does it means that unpack just forwards to unpack_sequence? Does the default specialization make use of INVOKE? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/capture.html*** Please, could you show how it is more flexible than lambda captures in C++? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/if.html* What happens when the parameter is false_type? SFINAE? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/limit.html*** if a function object is overloaded with 2 and 3 parameters, would limit be useful or it is only useful when the number of parameters is fixed? I believe this is answered in http://pfultz2.github.io/Fit/doc/html/doc/src/partialfunctions.html, however I believe it merits a clarification here. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat.html* Add requirement on the function parameter that must be a Unary function such that f(f(x)) is well formed. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat_while.html* The same here. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/arg.html*** What is the rational for the choice of been 1-based? Could you add a rationale in the doc? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/construct.html* Maybe add a reference to the factory proposal p03382. What happens when the parameter is not a T is not constructible from the params? SFINAE? What happens when the parameter is not a MetafunctionClass? SFINAE? I believe Boost.Hana uses make instead of construct. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/decay.html* Why not decay_copy? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/identity.html *is identity a function or a function object? do we need identity()(x)? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html*** Wondering if it is not better to locate them in a placeholders namespace, so that we can avoid possible collisions with other placeholders. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#unamed-placeholder* The same here *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function_param_limit.html*** |function_param_limit is not a Metafunction. "|The|function_param_limit| metafunction ..." *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/is_callable.html*** F must be Callable can not be a requirement ;-) Add reference to C++17 trait is_invocable. Wondering if we should have it in type_traits, if not already there. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/apply.html*** Confusion with std::apply. is this related to std::invoke? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function.html* "By default, all functions defined with|BOOST_FIT_STATIC_FUNCTION| use thereveal <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html> adaptor to improve error messages." How to change this default? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lift.html*** WhyBOOST_FIT_LIFT_CLASSdoesn't defines a instance as do BOOST_FIT_STATIC_FUNCTION? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pack.html*** How this is related with fit::capture? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/tap.html* How this is related to the tee unix command? *http://pfultz2.github.io/Fit/doc/html/doc/src/configurations.html***Which ones?

2 3

How to deal with unused variable with a BOOST_ASSERT check?
by James E. King, III 10 Sep '17

10 Sep '17

In serialization (boost/archive/iterators/mb_from_wchar.hpp) there is some code that generates a warning on release builds. We're always striving for warning-free code in all cases. Here's the snippet: std::codecvt_base::result r = m_codecvt_facet.out( m_mbs, & value, & value + 1, wend, m_buffer, m_buffer + sizeof(m_buffer), bend ); BOOST_ASSERT(std::codecvt_base::ok == r); Normally I'd say one should always check the result and throw an exception instead of relying on an assert. I'm sure consumers would like that more. That said, is there another macro that would allow me to change the code to do something like this? BOOST_ASSERT_ASSIGN_OR_IGNORE(std::codecvt_base::result r) m_codecvt_facet.out( m_mbs, & value, & value + 1, wend, m_buffer, m_buffer + sizeof(m_buffer), bend ); BOOST_ASSERT(std::codecvt_base::ok == r); where BOOST_ASSERT_ASSIGN_OR_IGNORE would expand to, assuming BOOST_ASSERT_ACTIVE is an indicator whether assert code is compiled in: #if BOOST_ASSERT_ACTIVE std::codecvt_base::result r = #else (void) #endif This would allow me to eliminate the warning without submitting a PR that changes the behavior of the code. If something like this does not exist, would it be useful for me to add it to boostorg/assert, or would folks recommend against encouraging this behavior and instead change it to use exceptions? Thanks, Jim

5 4

range/concepts.hpp broken on master
by Peter Dimov 09 Sep '17

09 Sep '17

Trying to, f.ex., build quickbook on master fails with an error like ./boost/range/concepts.hpp: In destructor 'boost::range_detail::SinglePassIteratorConcept<Iterator>::~SinglePassIteratorConcept()': ./boost/range/concepts.hpp:167:55: error: 'iterator_traits' in namespace 'boost::detail' does not name a type That's because boost/iterator/iterator_concepts.hpp used to include boost/detail/iterator.hpp, and no longer does since this commit: https://github.com/boostorg/iterator/commit/0107df44ab3ab41c46b616c9c37c30f… This apparently works on develop, which means that it's probably fixed in Range's develop branch, but the changes aren't in master.

1 2

[build] using nvcc as toolset target?
by Oliver Kowalke 09 Sep '17

09 Sep '17

Hello, a grep over the boost.config showed some code related to nvcc - but I could not figure out how to use nvcc together with b2. What is the toolset target for nvcc ('b2 toolset=nvcc' doesn't work)? Oliver

2 2

Why is the boost documentation so bad?
by Florian Lindner 08 Sep '17

08 Sep '17

Hello, I really love to use boost libraries in my project, but I always wonder, for such an accomplished project, why is the documentation so bad? A few examples: I want to get familiar with http://www.boost.org/doc/libs/1_65_1/libs/ptr_container/. What do I need to include? Neiter the tutorial, the reference or the usage guidelines mention a #include line. This is something which stroke me quite often at various boost libs. Also with the ptr_container lib, I want to find the refrence for the ptr_vector::insert function. I got to scan the reference pages of all members of it's class hierarchy to find the insert() function (it's in ptr_sequence_adapter). References and example code often have no syntax highlightning and no linking and it's extremely hard to find documentation for a specific symbol, or from there, to jump to the source code. I would really like to have a more uniform and a documentation that not feels like a annotated source code dump. I use doxygen for my own projects and I know it can generate nicely looking, with syntax highlightning and linked documentation. Please, don't take this offensive, it's just some feedback I wanted to give a long time. Best, Florian

12 13

[release] 1.66.0 open for merging
by Daniel James 08 Sep '17

08 Sep '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

Re: [boost] (no subject)
by degski 08 Sep '17

08 Sep '17

On 7 September 2017 at 17:37, Pranam Lashkari <plashkari628(a)gmail.com> wrote: > Hello, > > I recently joined boost community. I am an engineering student from India. > I don't have much experience with contributing in open source. > > Can you please help me getting started with it? > > From where I can/should start contributing this community..? > > Thank you. > Hi Pranam, You have to write to the boost mailing list: boost(a)lists.boost.org (and ask there) See also http://www.boost.org/community/groups.html for some "rules and regulations" and the need for "subscription". You can find the archives (old posts) here: https://lists.boost.org/ Archives/boost/ In the archive you'll see that your question has been asked (many times) before, answers where to start are also given in the follow-up to those questions. Personally, I would like to see Boost.Pool being brought up to the current C++ standard (C++17). That would be a nice little project. I believe Edward Diener is the current curator of that particular library. See you on the list and have a good day (and don't forget to subscribe), degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 0

[gsoc] Change in Google Summer of Code admin
by Niall Douglas 07 Sep '17

07 Sep '17

Dear all, Google Summer of Code 2017 has ended with another successful summer of student coding with probably the highest calibre year we've ever seen. After four years as lead admin for Boost Summer of Code, my time has come to an end. I'll be making way for David Bellot, long time mentor at Boost GSoC and maintainer of Boost.uBLAS. Please join me in welcoming David as new lead admin. I'll be staying on as backup admin next summer to help David settle in. My time as Boost Summer of Code admin has certainly been eventful with lots of surprises, ups and downs. The fact these surprises did not turn into crises is due in large part to a few people in particular who went far beyond the call of duty: * Jon Kalb, who went to bat for the students repeatedly in multiple venues and finding tens of thousands of dollars when it was needed. * Boris Schäling, whom I replaced as lead admin and who acted as backup admin for some years, who also managed to arrange tens of thousands of dollars of sponsorship when it was needed most. * Bryce Adelstein Lelbach, for acting as backup admin these past few years. * Andrew Sutton, the lead GSoC admin before Boris, who gave such detailed and useful early advice and materials on how to best navigate the treacherous waters of Google Summer of Code! And finally to all the mentors who so generously volunteered their time, and to the students every single one of whom successfully finished their projects in my time as admin despite problems with sickness, deaths in close family etc. Some of those students have gone on to become mainstays of the C++ conference circuit, famous names in their own right. I'm sure they would have been so without Google Summer of Code, but I'd like to think that it helped bring them to Boost rather than them getting into C++ via elsewhere. Thank you students! Regards, Niall

5 5

master and develop branches
by James E. King, III 07 Sep '17

07 Sep '17

Could someone point me to documentation on management of the master and develop branches for committers? boostorg/uuid master ends at Jan 11. boostorg/develop has a bunch of stuff in it starting on August 3, 2017. Who is responsible for merging develop into master and when should that happen? Some of the issues are already marked resolved with a milestone of 1.66.0 but they are not in master, only develop. Should pull requests on github go directly into master? I find it confusing to have both and would prefer if there was only one possible destination for pull requests on github. If there are two, someone has to keep one of them updated and that isn't very efficient. Thanks, Jim

4 3

Libraries maintained by CMT?
by James E. King, III 07 Sep '17

07 Sep '17

Hello, I was wondering if there's a page/location that lists the libraries currently being maintained by the community maintainer team? I recently assumed responsibility for maintaining boost::uuid and I was wondering if there was a list that needs to be modified. Thanks, - Jim

4 5

[release] Boost 1.65.1
by Daniel James 07 Sep '17

07 Sep '17

Release 1.65.1 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 bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/history/version_1_65_1.html> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.65.1/> 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

1 0

Appveyor and Travis CI for pull requests
by James E. King, III 07 Sep '17

07 Sep '17

Some of the repositories have Appveyor and Travis CI build configuration files in them. I don't see this translating into automatic builds on top of each pull request. I'd like to get the uuid library to the point where a pull request builds on Appveyor and on Travis, so that it is easier to validate the code changes are okay. Could someone let me know if this is possible and if so, how? Thanks, Jim

3 2

[pool] variadically templated object_pool.construct()
by degski 07 Sep '17

07 Sep '17

I would like to request to bring object_pool.hpp up-to-date (all the way to 2011) and include a member function with this signature: template<typename ... Args> element_type * construct( Args && ... args_ ); degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 2

[1.65.1] Release tomorrow
by Daniel James 06 Sep '17

06 Sep '17

Hi, I'm planning on releasing tomorrow. I've written up some release notes: http://www.boost.org/users/history/in_progress.html Let me know if you want any changes to them. Daniel

2 2

[stacktrace] Not working on Cygwin
by Phil Bouchard 06 Sep '17

06 Sep '17

Hi, I tried stacktrace on Cygwin and after tweaking some local and system headers I was able to compile libboost_stacktrace_windbg.a and libboost_stacktrace_addr2line.a but when I run my application calls to boost::stacktrace::stacktrace(1, 1) doesn't output anything. It works fine under Linux using libboost_stacktrace_backtrace.a. Thanks in advance for your help, -Phil

2 2

Upcoming Boost.Fit Review (September 8th-17th)
by Matt Calabrese 05 Sep '17

05 Sep '17

Hi everyone, This coming Friday, September 8th, marks the start of review of the Fit library by Paul Fultz II. Source: https://github.com/pfultz2/Fit Docs: http://fit.readthedocs.org/ This is the second time that the library will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed. The following is a brief description of the library from its author: ========== Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: - Function Adaptors and Decorators: These enhance functions with additional capability. - Functions: These return functions that achieve a specific purpose. - Utilities: These are general utilities that are useful when defining or using functions. ========== Requirements¶ <http://fit.readthedocs.io/en/latest/doc/src/index.html#requirements> This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported. Contexpr support¶ <http://fit.readthedocs.io/en/latest/doc/src/index.html#contexpr-support> Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION <http://fit.readthedocs.io/en/latest/doc/src/FIT_STATIC_FUNCTION> and FIT_STATIC_LAMBDA_FUNCTION <http://fit.readthedocs.io/en/latest/doc/src/FIT_STATIC_LAMBDA_FUNCTION> constructs. Noexcept support¶ <http://fit.readthedocs.io/en/latest/doc/src/index.html#noexcept-support> On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this. ========== Please take this time to become familiar with the Fit library before the review takes place and feel free to respond in this thread with any additional questions related to the library or its review. Thanks! -- -Matt Calabrese

1 0

Boost.TR1 silently removed with 1.65?
by Tim Rakowski 04 Sep '17

04 Sep '17

Hi, I noticed that boost 1.65 does not contain the tr1 folder and found that the documentation was updated accordingly: http://www.boost.org/doc/libs/1_64_0/ contains http://www.boost.org/doc/libs/1_64_0/libs/tr1/, while http://www.boost.org/doc/libs/1_65_0/ has no http://www.boost.org/doc/libs/1_65_0/libs/tr1/. But http://www.boost.org/users/history/version_1_65_0.html <http://www.boost.org/users/history/version_1_65_0.htmldoes> does not mention this. Even if it was deprecated, shouldn't this be mentioned somewhere? Googling "site:https://lists.boost.org/Archives/boost/ 1.65 tr1" didn't yield anything either :/ Regards, Tim

1 0

[contract] Ready to release
by Lorenzo Caminiti 04 Sep '17

04 Sep '17

Hello all, I *finally* got around finishing Boost.Contract after the library was reviewed and accepted by Boost about 5 years ago?! (review results: https://groups.google.com/forum/?fromgroups=#!topic/boost-list/jQ7OjAmos_Y) Documentation: https://lcaminiti.github.io/boost-contract/doc/html/index.html Source: https://github.com/lcaminiti/boost-contract * All Contract Programming features (a.k.a., Design By Contract, DBC) are supported: subcontracting, class invariants, postconditions (with old and return values), preconditions, customizable actions on assertion failure (terminate, throw, etc.), optional compilation of assertions, disable assertions while already checking other assertions (to avoid infinite recursion), etc. * Leveraging the convenience of C++11 lambdas, this revision of the library no longer requires "crazy" macros that alter C++ declaration syntax. That makes the library much easier to use, faster to compile, and generates readable compiler errors on misuse. I was thinking to add Boost.Contract to the next, or next next, Boost release... Thanks, -- --Lorenzo

2 2

Boost 1.65.2 Release Candidate 2
by Daniel James 04 Sep '17

04 Sep '17

The second release candidates for the 1.65.1 release are now available at: <https://dl.bintray.com/boostorg/release/1.65.1/> The SHA256 checksums are as follows: df7bea4ce58076bd8e9cd63966562d8cf969b431e1c587969e6aa408e51de606 boost_1_65_1_rc2.7z 9807a5d16566c57fd74fb522764e0b134a8bbe6b6e8967b83afefd30dcd3be81 boost_1_65_1_rc2.tar.bz2 a13de2c8fbad635e6ba9c8f8714a0e6b4264b60a29b964b940a22554705b6b60 boost_1_65_1_rc2.tar.gz d1775aef807bd6a14077b450cce2950d8eacd86aaf51015f79e712917f8cc3c2 boost_1_65_1_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.

3 3

To start contributing to boost
by Yaghyavardhan Singh Khangarot 03 Sep '17

03 Sep '17

Hello boost community, My name is Yaghyavardhan Singh, a 3rd year CS undergrad at IIIT, Hyderabad. I have been using Boost C++ Library for quite some time now and I would like to contribute to it. I have sound knowledge of C++(along with STL) and Advanced data structures and algorithms. As I am new to open source, I need some help to get started. I would be interested to add any new algorithms which might not be part of any specific module yet(say some optimized convex hull algorithm in boost.geometry). I am also open to optimization problems. Thank you, Your's Sincerely, Yaghyavardhan Singh

3 3

[build][wave][thread][date-time] 1.65.0 clang on Windows build failures
by Konstantin Ivlev 02 Sep '17

02 Sep '17

Hi, I am trying to compile boost 1.65.0 on Windows via clang 4.0.1 with the following user-config.jam: using clang : 4.0 : "C:/Program Files/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe" <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe" <linkflags>-fuse-ld=lld ; and there are few issues. 1. clang.jam ignores ranlib/archiver settings. currently there is the PR https://github.com/boostorg/build/pull/232 against clang-darwin.jam, and I suppose the same should be applied to the clang-linux.jam. 2. there are numerous errors in boost wave: .\boost/wave/grammars/cpp_expression_grammar.hpp:829:18: error: case value evaluates to -804257404, which cannot be narrowed to type 'unsigned int' [-Wc++11-narrowing] case T_CPPCOMMENT: // contains newline (about 100 errors of such kind for various enumerations) 3. WinAPI-related errors in boost::date_time & boost::thread, e.g. In file included from libs\coroutine\src\windows\stack_traits.cpp:23: In file included from .\boost/thread.hpp:13: In file included from .\boost/thread/thread.hpp:12: In file included from .\boost/thread/thread_only.hpp:15: In file included from .\boost/thread/win32/thread_data.hpp:10: In file included from .\boost/thread/thread_time.hpp:10: In file included from .\boost/date_time/microsec_time_clock.hpp:23: .\boost/date_time/filetime_functions.hpp:57:46: error: conflicting types for 'GetSystemTimeAsFileTime' __declspec(dllimport) void __stdcall GetSystemTimeAsFileTime(FILETIME* lpFileTime); ^ C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\um\sysinfoapi.h:159:1: note: previous declaration is here GetSystemTimeAsFileTime( ^ seems like stack_traits.cpp unconditionally includes windows.h, while BOOST_USE_WINDOWS_H is not defined in case of clang build, so filetime_functions.hpp defines its own WinAPI prototypes. probably shall be somehow fixed in boost config? any advice on how to proceed with these issues?

3 4

[release] Boost 1.65.1 Release Candidate 1
by Daniel James 01 Sep '17

01 Sep '17

The release candidates for the 1.65.1 release are now available at: <https://dl.bintray.com/boostorg/release/1.65.1/> The SHA256 checksums are as follows: 9b440d8167043c8d70326d8a5d4df98a59abb40be7d68f51e75ea95ea24d84f3 boost_1_65_1_rc1.7z fbd5663c748a88479adb4106c8a12009b149e602dec4b40a4a778381a33cf3ce boost_1_65_1_rc1.tar.bz2 b1b18d658cc0ff8a5030b29f4ed41de1826281fcb52fc1073b106c5802a570bd boost_1_65_1_rc1.tar.gz 542624352b2c3fd6a76c98624f90d2c0e62dd810ec6cc9fdae831677c7aa1fbf boost_1_65_1_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 7

[regression] [date_time] Tests table damaged
by Andrey Semashev 01 Sep '17

01 Sep '17

Hi, It looks like Boost.DateTime table got damaged: http://www.boost.org/development/tests/develop/developer/date_time.html One of the table cells contains this text: lin/home/www/live.boost.org/common/code/boost_archive.php:149: Cannot modify header information - headers already sent by (output started at /home/www/live.boost.org/common/code/boost_archive.php:91) and there are no test results visible past this cell.

2 2

[iterator] generator_iterator vs. function_input_iterator
by Andrey Semashev 01 Sep '17

01 Sep '17

Hi, There seems to be two nearly equivalent components in Boost.Iterator: generator_iterator (moved from Boost.Utility) and function_input_iterator. Both are input iterators wrapping a function object, which result is used as the dereferenced value. The difference is: - generator_iterator always creates an instance of the element type while function_input_iterator does that lazily; - function_input_iterator uses result_of while generator_iterator relies on C++03 T::result_type - equality comparison is different: generator_iterators compares equal if both refer to the same generator and cached element instances are equal while function_input_iterator uses an additional state (which can be viewed as an index) for comparison instead of the cached element. So basically, they are the same thing. generator_iterator looks a bit more dated and IMHO its comparison implementation is not as robust as that of function_input_iterator, so maybe we should deprecate it?

4 6

[release] Starting 1.65.1
by Daniel James 30 Aug '17

30 Aug '17

Hello all, As no one objected, I'm starting work on a point release. This release should only include fixes and documentation changes, and please keep your changes to a minimum - I'm not looking for any minor changes, such as compiler warning fixes. If I can cleanly incorporate changes from your master branch, let me know the commit hash. Otherwise, please create a branch from the boost-1.65.0 tag called 'fixes/1.65' and cherry pick the required changes onto that branch. All changes should already be included in both your develop and master branches. If a commit doesn't cleanly apply, then we'll have to work something out, but please try to avoid that. If you want any help with this, let me know. The quickbook file for the release notes is at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_65_1.q… I'll set a schedule in the next few days, but I want to get the changes finalised as soon as possible, so don't wait around, I think it will have to be pretty tight. thanks for you help, Daniel

10 27

GitHub issues for superproject
by Olaf van der Spek 30 Aug '17

30 Aug '17

Hi, James wrote: > I would have opened up a github issue on the superproject to track this and resolve it, however the "issues" section is not activated for the superproject. Why's this? IMO it'd be nice to track issues there. As a Boost user I vastly prefer GitHub over Trac. -- Olaf

1 0

Superproject 1.55.0 tags incorrect for libs/uuid?
by James E. King, III 29 Aug '17

29 Aug '17

Hello, Someone reported a discrepancy in boost trac that needs to be investigated by folks on the superproject team. What is claimed is that the superproject tag for boost-1.55 contains commit id 8c395a888c2d77bdc91e956ef24a07c0c87cdd24 for uuid, however this commit id does not exist. The tag id in the boost/uuid repository points to commit 98cf8322aef86e6398dbac7f9cd6bf766621d645. I would have opened up a github issue on the superproject to track this and resolve it, however the "issues" section is not activated for the superproject. https://svn.boost.org/trac10/ticket/13071 Instructions given to reproduce the issue are as follows: git clone https://github.com/boostorg/boost.git cd boost git submodule init libs/uuid git checkout boost-1.55.0 git submodule update libs/uuid and the last step will fail with: fatal: reference is not a tree: 8c395a888c2d77bdc91e956ef24a07c0c87cdd24 Unable to checkout '8c395a888c2d77bdc91e956ef24a07c0c87cdd24' in submodule path 'libs/uuid' Thanks, Jim

2 1

Interest in thermodynamic properties of water and steam
by Belcourt, Kenneth 29 Aug '17

29 Aug '17

Hi, Would there be any interest in an implementation of the IAPWS-95 in Boost? Here’s the reference: The IAPWS Formulation 1995 for the Thermodynamic Properties of Ordinary Water Substance for General and Scientific Use. Authors: W. Wagner and A. Pruss J. Phys. Chem. Ref. Data, Vol. 31, No. 2, 2002, pages 387-535 For those with access to the paper, the code reproduces Table 6.6 (results agree to all published digits), as well as well significant parts of both Table 13.1 (vapor-liquid phase boundary properties as function of temperature) and Table 13.2 (properties of water in single-phase as function of temperature and density for pressures in range of 0.05 MPa to 1000 MPa). Also implemented are the full set of algorithms in Table 6.3, including pressure, enthalpy, entropy, sound speed, heat capacities. There’s also an algorithm for computing the thermal saturation properties (pressure, liquid and vapor densities), given the saturation temperature. At present the code has a required dependency on Boost.Units and is about 2k loc. If you're interested in this, feel free to reply or contact me directly. — Noel Belcourt [1] http://www.iapws.org

7 10

Question/Remark to your include/boost/numeric/ublas/lu.hpp
by Ziehe, Dieter 29 Aug '17

29 Aug '17

Dear development community, first of all, thanks for your work, I use boost sometimes to ease from it in my development of math algorithm. Normally I try and check your code and documentation till it works (for example Edmonds karp, remez ...) But now I came to one point, which I don't understand and only workarounded it (although I'm a mathematician and the topic LU-Decomposition is easy). My Problem is lu.hpp:: lu_factorize and this part : (*) #if BOOST_UBLAS_TYPE_CHECK swap_rows (pm, cm); BOOST_UBLAS_CHECK (singular != 0 || detail::expression_type_check (prod (triangular_adaptor<matrix_type, unit_lower> (m), triangular_adaptor<matrix_type, upper> (m)), cm), internal_logic ()); #endif Despite the fact, that I can BOOST_UBLAS_TYPE_CHECK switch off (with BOOST_UBLAS_NDEBUG) I don't understand the sense of these lines. As far as I know, LU is in every case possible, either a matrix is singular or not. For example the ZERO-Matrix is also LU- decomposable (Solution ZERO-Matrix and Identity Matrix). And so, IMHO the lines are too strong for this situation. These lines lead in remez to an Exception : remez failed with exception: internal logic , but the remez algorithm is right (without BOOST_UBLAS_TYPE_CHECK) I got the correct results. Is it possible to weaken the lines (*) to a hint only (the return-value singular is also available for other user, who need regularity). Maybe I'm wrong. But if so, I'd like to know the argument, which lead to such strong reaction in the normal case of singular Matrix inside the LU-Algorithm ? I'm looking forward to hear from you. Many thanks. Dieter from Berlin

1 0

[Intrusive]
by degski 28 Aug '17

28 Aug '17

I having trouble understanding the documentation of Boost.Intrusive. I'm referring to this section in particular: http://www.boost.org/doc/libs/1_65_0/doc/html/intrusive/intrusive_vs_nontru… "The main difference between intrusive containers and non-intrusive containers is that in C++ non-intrusive containers store *copies* of values passed by the user." This is confusing, as that might not be true in case of C++11 and up. Does (or rather, can) move-construction invalidate the use case for Intrusive containers? "On the other hand, an intrusive container does not store copies of passed objects, but it stores the objects themselves. The additional data needed to insert the object in the container must be provided by the object itself." But then in the example for slist, it seems from the example code that (a) pointer(s) to the original object are stored (and makes it look like the object), but that's not what I read from the quoted text. class MyClass{ MyClass *next; MyClass *previous; //Other members...}; int main(){ acme_intrusive_list<MyClass> list; MyClass myclass; list.push_back(myclass); //"myclass" object is stored in the list assert(&myclass == &list.front()); return 0;} I would like to ask for somebody to confirm I'm right, or explain to me in language (palatable to a thick user) what is actually stored (in terms of implementation). Thanks in advance, degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

5 19

[detail] boost/detail/utf8_codecvt_facet.hpp broken by recent change
by Beman Dawes 28 Aug '17

28 Aug '17

boost/detail/utf8_codecvt_facet.hpp fails to compile for STL's MinGW distro from https://nuwen.net/mingw.html The error message is: ..\..\../boost/detail/utf8_codecvt_facet.hpp:117:29: error: function 'boost::filesystem::detail::utf8_codecvt_facet::~utf8_codecvt_facet()' definition is marked dllimport virtual BOOST_UTF8_DECL ~utf8_codecvt_facet(){} The problem (on develop) is caused by Robert Ramey's Aug 13 commit 73c12230c31a851c15ecb9a649468425ebd92f8e "adjustment to avoid linking problem: vtable not found found for ~utf8_codecvt_facet.hpp" which added "BOOST_UTF8_DECL" to line 117. This is breaking my local filesystem tests for GCC/MinGW. If the change is reverted, the tests start passing again. Robert, could you please revert the change? I can also to it, but thought you needed to be alerted first so you can revisit whatever you were trying to fix. Thanks, --Beman

4 6

[release] 1.65.1 closing on Thursday
by Daniel James 28 Aug '17

28 Aug '17

Hi, I've added a schedule for 1.65.1 to the calendar: http://www.boost.org/development/ I think it should be possible to get the changes ready in the next two days, although the schedule is a little flexible. I might also release a little early if everything goes smoothly. We don't want to spend too much time on this. Daniel

2 2

[iterator] What documentation is actual?
by Andrey Semashev 27 Aug '17

27 Aug '17

Hi, While moving next_prior.hpp to Boost.Iterator I've noticed that thete are basically two versions of the documentation in Boost.Iterator: rst and QuickBook. It seems like QuickBook is in progress of being written and is largely a conversion of rst, but is incomplete in some places. I'd like to ask what's the plan about it? Since I don't know rst I converted the original documentation of next_prior.hpp to QuickBook and added it to the current QuickBook docs. I also converted advance() and distance() docs to QuickBook and fixed a few problems in the docs so that it is at least browsable and readable. If we have no plans to switch to QuickBook then I suppose it is better to remove them to avoid confusion. Also, someone has to convert next_prior.hpp docs to rst (I don't know how to do this).

3 8

Purchasing Travis Resources for boostorg (was Re: [1.65.0] Point release?)
by Tom Kent 27 Aug '17

27 Aug '17

On Sat, Aug 26, 2017 at 1:16 PM, Daniel James via Boost < boost(a)lists.boost.org> wrote: > On 26 August 2017 at 18:02, Peter Dimov via Boost <boost(a)lists.boost.org> > wrote: > > Daniel James wrote: > > > But we don't rely that much on the testers nowadays, so this would be > less > > of an issue. > > I do. The turnaround on Travis is pretty terrible at the moment, and > that's going to get worse as more modules use it. While I'm a big fan of Boost's test system, and believe that it is an awesome resource that can't be replicated on the common CI services (lots of platforms and compiler versions/configs!), I also think that good per-commit CI on a service like travis is hugely important. Maybe someone should present a proposal to the steering committee to start paying for boostorg's account to have additional build resources? Tom

9 9

[1.65.0] Point release?
by Daniel James 27 Aug '17

27 Aug '17

Hello all, What do you think about having a point release? I tried asking the other release managers but didn't get any reply. Some are away, and I don't known when they will be available again. I think we have to decide soon, as it's holding up development. This would deal with the issues in thread, context, fiber, and possibly others. I've added patches to the release notes: http://www.boost.org/users/history/version_1_65_0.html A point release should take a week or two, perhaps more if we include other changes. thanks, Daniel

7 18

[Boost-build] Broken installation with `./b2 --prefix=/tmp/boost --with-stacktrace install`
by Antony Polukhin 26 Aug '17

26 Aug '17

Hi, People complain about the broken installation. Command `./b2 --prefix=/tmp/boost --with-stacktrace install` does not copy the boost/stacktrace/detail/push_options.pp and boost/stacktrace/detail/pop_options.pp files into the destination folder. See https://github.com/boostorg/stacktrace/issues/29 How this could be fixed? Is that a b2 issue? -- Best regards, Antony Polukhin

3 2

boost.process 1.64.0 and 1.65.0 are equal
by Egor Pugin 26 Aug '17

26 Aug '17

Hi, See https://github.com/boostorg/process/releases Both boost/process 1.64.0 and 1.65.0 have same commit 4075371. Looks like that boost process 1.65.0 was not updated. Is this a bug or feature? For reference, this was detected in https://github.com/klemens-morgenstern/boost-process/issues/121 -- Egor Pugin

2 1

Important Regression of Boost.Thread on Windows
by Vicente J. Botet Escriba 26 Aug '17

26 Aug '17

Hi, there is an important regression of Boost Thread on Windows https://github.com/boostorg/thread/issues/130 windows: Bug in boost::condition_variable on Windows Please, merge these two patches 1 https://github.com/boostorg/thread/commit/fdc0cbcd8ce8f34a19c7cdaf6f1fa679f… 2 https://github.com/boostorg/thread/commit/395e3d786bc1dce9c60eb84da85f5845a… I've sent a PR for the boost-1.65 release notes https://github.com/boostorg/website/pull/267 If there is a 1.65.1 point release, this issue should be a good candidate. Sorry for the disturbance Vicente

1 0

1.65 build failure on FreeBSD 11.1
by rleigh＠codelibre.net 26 Aug '17

26 Aug '17

The error is "boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace". The details are below. A creeping Linux-ism? Regards, Roger $ clang++ --version FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd11.1 Thread model: posix InstalledDir: /usr/bin $ uname -a FreeBSD brill 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -- Building boost (Unix) with toolset=clang cxxflags= -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include linkflags= -L/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - symlinks supported : yes - C++11 mutex : no - lockfree boost::atomic_flag : yes - Boost.Config Feature Check: cxx11_auto_declarations : no - Boost.Config Feature Check: cxx11_constexpr : no - Boost.Config Feature Check: cxx11_defaulted_functions : no - Boost.Config Feature Check: cxx11_final : no - Boost.Config Feature Check: cxx11_hdr_mutex : no - Boost.Config Feature Check: cxx11_hdr_tuple : no - Boost.Config Feature Check: cxx11_lambdas : no - Boost.Config Feature Check: cxx11_noexcept : no - Boost.Config Feature Check: cxx11_nullptr : no - Boost.Config Feature Check: cxx11_rvalue_references : no - Boost.Config Feature Check: cxx11_template_aliases : no - Boost.Config Feature Check: cxx11_thread_local : no - Boost.Config Feature Check: cxx11_variadic_templates : no - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes - bzip2 : yes - lzma : yes - iconv (libc) : yes - icu : yes - xlocale supported : yes - native-atomic-int32-supported : yes - native-syslog-supported : yes - pthread-supports-robust-mutexes : yes - compiler-supports-visibility : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no - addr2line builds : yes - WinDbg builds : no - WinDbgCached builds : no Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - metaparse : building - mpi : building - program_options : building - python : not building - random : building - regex : building - serialization : building - signals : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building [...] clang-linux.compile.c++.without-pth bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/addr2line.o "/usr/bin/CC" -c -x c++ -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -O3 -Wno-inline -Wall -pedantic -pthread -fPIC -m64 -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -DBOOST_ALL_NO_LIB=1 -DBOOST_STACKTRACE_DYN_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/addr2line.o" "libs/stacktrace/build/../src/addr2line.cpp" In file included from libs/stacktrace/build/../src/addr2line.cpp:10: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/frame_unwind.ipp:15: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/frame.hpp:20: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/safe_dump_to.hpp:213: /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace ::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback, &state); ~~^ 1 error generated. ...skipped <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_addr2line.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>addr2line.o... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_addr2line.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_addr2line.so.1.65.0... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_addr2line.so for lack of <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_addr2line.so.1.65.0... clang-linux.compile.c++.without-pth bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/basic.o "/usr/bin/CC" -c -x c++ -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -O3 -Wno-inline -Wall -pedantic -pthread -fPIC -m64 -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -DBOOST_ALL_NO_LIB=1 -DBOOST_STACKTRACE_DYN_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi/basic.o" "libs/stacktrace/build/../src/basic.cpp" In file included from libs/stacktrace/build/../src/basic.cpp:9: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/frame_unwind.ipp:15: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/frame.hpp:20: In file included from /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/safe_dump_to.hpp:213: /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include/boost/stacktrace/detail/collect_unwind.ipp:55:7: error: no member named '_Unwind_Backtrace' in the global namespace ::_Unwind_Backtrace(&boost::stacktrace::detail::unwind_callback, &state); ~~^ 1 error generated. ...skipped <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_basic.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>basic.o... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_basic.so.1.65.0 for lack of <pbin.v2/libs/stacktrace/build/clang-linux-4.0.0/release/threading-multi>libboost_stacktrace_basic.so.1.65.0... ...skipped <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_basic.so for lack of <p/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/lib>libboost_stacktrace_basic.so.1.65.0... common.mkdir bin.v2/libs/timer

5 5

Bug in Boost-1.65 Windows binaries.
by Stefan Seefeld 25 Aug '17

25 Aug '17

Hello, I just received a bug report (https://github.com/boostorg/python/issues/129) related to the Boost 1.65 Windows binaries. Not being able to reproduce the error when building from source myself (on Windows), I wonder where to file issues that are specific to the Windows binaries. Does that have a dedicated maintainer ? (The bug is that the Boost.Python libraries built for Python3 actually link to Python27.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 1

[github] Super-project not updating.
by Rene Rivera 25 Aug '17

25 Aug '17

It seems that the super-project is not getting updated for any branch since yesterday. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[trac][poly_collection][stacktrace] request for Trac components
by Joaquin M López Muñoz 25 Aug '17

25 Aug '17

Hi, Can a "poly_collection" component (assigned to me) be added to the Trac ticketing system? I guess Vinnie'll need a "stacktrace" component, too. Thank you, Joaquín M López Muñoz

2 2

fix release for 1.65?
by Oliver Kowalke 25 Aug '17

25 Aug '17

Hello, is a fix-release for 1.65 possible? It seams that the fixes that were too late to get merged into 1.65 are need to prevent segfaults in 1.65. Oliver

3 7

[Root.Ptr] C Crash Proof - Completed
by Phil Bouchard 25 Aug '17

25 Aug '17

Greetings, Most of you know the former programming language I was working on: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp I decided to turn this into a C parser which converts C code into C++ and adds the memory manager I wrote plus other utilities to detect the exact location the memory leaks (missing call to free()). It works with traditional missing sequential calls to free() and even references that are cyclic as you can see in the attached example (input2.c). Please note that the attached C code uses basic C++ functionality such as constructors and destructors to help having a descriptive output (input2.txt). So if you have such a memory leak problem in C then please let me know and I'll be happy to offer consulting services, remotely preferably, to the employer you're working for. The problem should be solved fairly quickly. On my side I will perhaps improve the parser if necessary and automate the whole process soon. All the best! -Phil Note: For the moment the size of arrays allocated with malloc() needs to be a compile-time constant and the returned line number is not precise.

1 0

[config] BOOST_STATIC_CONSTEXPR in C++11 vs C++14
by Lakshay Garg 23 Aug '17

23 Aug '17

This conversation is in reference to https://github.com/boostorg/math/pull/82 but I'm posting it here because it might be of interest to some. On 22 August 2017 at 13:53, jzmaddock <notifications(a)github.com> wrote: > Note that those changes don't actually make the functions constexpr - or > indeed change the way the constants are initialized - in fact in C++14 > BOOST_STATIC_CONSTEXPR doesn't even imply the constants are "const > (C++11 is different, and early implementations prevent you from writing > "constexpr const" which is what C++14 permits). Since BOOST_STATIC_CONSTEXPR behaves differently in C++11 and 14, would it be a good idea for boost.config to provide a macro for handling the `static const var = ...;` kind of variable initializations in a portable manner? Maybe something like BOOST_COMPILETIME_CONSTANT? Such a macro might will be useful for declarations where we want the variable to be a constant in all possible senses (compile-time, run-time) and allow generating the most optimal code possible with the language version, compiler being used in a portable manner. An example of the kind of constants I am talking about can be seen here: https://github.com/boostorg/math/blob/develop/include/boost/math/special_fu… Lakshay

5 8

Review Request: impl_ptr (pimpl)
by Vladimir Batov 22 Aug '17

22 Aug '17

After much procrastination I would like to request a formal review for the pimpl library... once and for all :-) (given it's been through a few almost-reviews and discussions)... to get some kind of a resolution one way or the other. :-) On one hand it is embarrassingly simple and no match to a string of late TMP submissions. On the other hand it seems quite handy for ordinary s/w folk (like me) as it formalizes, streamlines and noticeably simplifies (IMO) pimpl-based deployments and makes code-review process quite simple and straightforward. Its benefits are more visible for pimpls with exclusive-ownership proxy-implementation relationships (value-semantics pimpls) as it uses internally an incomplete-type management smart pointer instead of std:unique_ptr. Given that it is policy-based I am hoping others might get interested writing additional policies within that framework such as COW or stack-based. The major oddity/peculiarity (that caused a stir before and Gavin mentioned about a year ago) is that the main class -- impl_ptr -- is declared in the global namespace. That might happen to be a deal breaker but that's the best I could come up with to get it to work. If anyone has a better working solution, I am all ears. That "oddity" is an "implementation detail" and does not affect the user -- from the user side it appears inside boost. Like boost::impl_ptr... Internally to address that we might think of striking a compromise. For ex., instead of the traditional namespace boost { template<> class impl_ptr } have template<> class _boost_impl_ptr_ Again, that is an implementation nit, wrinkle, niggle (IMO anyway). From the outside it all looks kosher -- boost::impl_ptr<...> and such. The code and the docs are at https://github.com/yet-another-user/pimpl <https://github.com/yet-another-user/pimpl>. Due to personal circumstances Glen -- Pimpl's original manager -- had to bail out. So, if anyone kindly steps forward to manage the review, that'd be immensely appreciated. Thank you, Vladimir. P.S. Ron, I am only CCing you so that you'd put it to the schedule... Tnx.

9 28

[release] Boost 1.65.0
by Daniel James 22 Aug '17

22 Aug '17

Release 1.65.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 two new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/history/version_1_65_0.html> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.65.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

6 5

[math] regression tests failing in develop (2017-08-21)
by Ion Gaztañaga 22 Aug '17

22 Aug '17

I'm receiving the following error in my runners: error: Unable to find file or target named error: 'polynomial_concept_check.cpp' error: referred to from project at error: '../libs/math/test' It seems related to the following change: https://github.com/boostorg/math/commit/f6495af64c05416ed098d6acf6da70911c7… Best, Ion

3 3

Broken unary_functions in numeric conversions
by Gary Furnish 22 Aug '17

22 Aug '17

SHA-1: 2009f0d4fc49a6db59b950a3140f8d1f58e1a8c6 * Revert "removed deprecated std::unary_function from various conversion functors" This reverts commit 593aafab5a7aba86f14df5f9a14a53fc4353bb00. Without this commit boost\libs\numeric\conversion\include\boost\numeric\conversion\detail\converter.hpp is broken on MSVC C++17. (See https://svn.boost.org/trac10/ticket/12972) This is still fixed in develop, does anyone know why the changes were reverted? Can we get someone to actually recommit a fix? Is numeric conversion abandoned? It doesn't look like it has been touched in over a year. Thanks

5 8

[math] mark constants as constexpr
by Lakshay Garg 21 Aug '17

21 Aug '17

Hello all The boost.math library stores quite a few constants for improving performance of various operations (example: boost/math/special_functions/detail/unchecked_factorial.hpp). I was wondering if marking these constants as constexpr would be desirable. Please provide feedback / suggestions so that I can get started :) Lakshay

2 4

Property Tree Maintainer
by Gary Furnish 21 Aug '17

21 Aug '17

I've emailed Sebastian Redl <sebastian.redl -at- getdesigned.at> and never got a responce, is property tree abandoned? There are a bunch of PRs (including mine at https://github.com/boostorg/property_tree/pull/29) piling up on github. I'm not exactly sure what the procedure is if it is, but maybe we could get some love for PRs from community maintainers or something? Thanks,

2 1

Boost 1.65.0 Release Candidate 5
by Daniel James 20 Aug '17

20 Aug '17

Hello everyone, The fifth release candidate for the 1.65.0 release is now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ [ Note: The RC1s/RC2s/RC3s/RC4s are in that directory, too - make sure you get the right files! ] It can also be downloaded from the 'in progress' release notes on the website: http://www.boost.org/users/history/in_progress.html Changes since RC4: * Fully qualify the name of a trait to fix an error in recent versions of Visual Studio. Changes since RC3: * Fix a bug in Boost.Thread where timed waits were waiting for a very long time. Changes since RC2: * Fix a crashing bug in Boost.ASIO * Fix a compilation error when including both <boost/math_fwd.hpp> and <boost/math/common_factor_ct.hpp> * An update to Boost.Spirit to fix compilation errors on Mac OS with -std=c++17 Changes since RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17 The SHA256 checksums are as follows: 4873d8f3506fd8d76e2eadcf0ace83b258010fc268a4d974361af7abad5448f5 boost_1_65_0_rc5.7z ea26712742e2fb079c2a566a31f3266973b76e38222b9f88b387e3c8b2f9902c boost_1_65_0_rc5.tar.bz2 8a142d33ab4b4ed0de3abea3280ae3b2ce91c48c09478518c73e5dd2ba8f20aa boost_1_65_0_rc5.tar.gz f3f5c37be45eb6516c95cd147d8aa4abb9b52121fc3eccc1fc65c4af0cf48592 boost_1_65_0_rc5.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. Thanks! -- The release managers

3 3

Boost 1.65.0 Release Candidate 4
by Marshall Clow 19 Aug '17

19 Aug '17

The fourth (and hopefully final) release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ [ Note: The RC1s/RC2s/RC3s are in that directory, too - make sure you get the right files! ] Changes since RC3: * Fix a bug in Boost.Thread where timed waits were waiting for a very long time. Changes since RC2: * Fix a crashing bug in Boost.ASIO * Fix a compilation error when including both <boost/math_fwd.hpp> and <boost/math/common_factor_ct.hpp> * An update to Boost.Spirit to fix compilation errors on Mac OS with -std=c++17 Changes since RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17 The SHA256 checksums are as follows: 5d255d1ff8460d52dffcf9a9b55d908ae704027a66c590ec774096effaea26c1 boost_1_65_0_rc4.7z 911602d830ea5d16483d1e565b9859d120d03f2e5176017226ef391eb9d17fc8 boost_1_65_0_rc4.tar.bz2 369e06dc787d32b0fbaae020f33d814c9e7b77263acb859776968e623035f760 boost_1_65_0_rc4.tar.gz a9c6b8346b05ea43ac4278e80036a9e956ea99fc61f0b7f55469471af2df934c boost_1_65_0_rc4.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. Thanks! -- The release managers

13 24

Improving Boost Docs
by Robert Ramey 17 Aug '17

17 Aug '17

I'm aware that at one point there was an initiative to improve boost documentation. See https://svn.boost.org/trac10/wiki/ImprovingBoostDocs It seems that the last movement here was 10 years ago. Does anyone know what the current status of this is? Does anyone still work on it? Does anyone know anything about it? I'm just curious about this. Robert Ramey

13 44

Need urgent help >> How to Handle Fragmentation in Boost's managed_shared_memory
by vijay sharma 17 Aug '17

17 Aug '17

I am using Boost::managed_shared_memory for my project. For allocate and deallocate we are using boost APIs as show in below example: shm_controller.reset(new boost::interprocess::managed_shared_memory( boost::interprocess::open_or_create, shmName, size));void * addr = shm_controller->allocate(size) ; shm_controller ->deallocate(addr); For this I have two question: 1) How can i handle fragmentation in this ? We are doing very frequent allocation and release. 2) What kind of allocation we are using in boost (slab, slub, slob) ? First question is very important for me. Please let me know if you want more info on any of these. Thanks, sharmavijay1991(a)gmail.com

3 2

Main page should link to some online compilers that include Boost
by Chambers, Matthew 17 Aug '17

17 Aug '17

Similar to https://isocpp.org/blog/2013/01/online-c-compilers but less of a blog post and more of an up-to-date list of online compilers where users can try out Boost immediately. Googling for this is tedious and it's certainly in Boost's best interest to encourage people to try it out (and make the barrier to do so as low as possible). -Matt

1 0

BOOST_STATIC_CONSTANT
by Vladimir Batov 17 Aug '17

17 Aug '17

There is something seemingly basic that puzzles me greatly. I am hoping people might clarify something I totally fail to understand. I've been using BOOST_STATIC_CONSTANT for ages (with GCC). Now I have something seemingly non-controversial: template<typename user_type> struct impl_ptr { using yes_type = boost::type_traits::yes_type; using no_type = boost::type_traits::no_type; using ptr_type = typename std::remove_const<user_type>::type*; template<typename Y> static yes_type test (Y*, typename Y::impl_ptr_type* =nullptr); static no_type test (...); BOOST_STATIC_CONSTANT(bool, value = (1 == sizeof(test(ptr_type(nullptr))))); }; When compiled with gcc-.5.4.0, both lines below pass: BOOST_TEST(true == boost::impl_ptr<Shared>::value); BOOST_TEST(true == boost::impl_ptr<Shared const>::value); The only difference between them is "const". However, when I compile with clang-4.0, the second (const) line passes. However, the first one fails! I refuse to believe it's a clang glitch. It must be me doing something really stupid. Help?!

6 14

VS2017 version 15.3
by Róbert Špir 17 Aug '17

17 Aug '17

Hi all, after upgrading my installation of vs2017 to version 15.3 (released two days ago) I'm receiving a lot of "Unknown compiler version - please run the configure tests and report the results" messages during building the project which uses boost (but everything builds and works fine). The cl.exe version in vs2017 15.3 was changed to 19.11.25506 Robert

5 7

patch for Intel compiler for new lib appeared in boost 1.65 beta
by Kurkov, Vasiliy A 17 Aug '17

17 Aug '17

Hi, I am Vasiliy Kurkov and I'm working as QA engineer in Intel Compiler QA team. I have tried to build boost libs from 1.65 beta, but I faced the following issue on Windows for new stacktrace lib: compile-c-c++ bin.v2\libs\stacktrace\build\07984f9e4da2f3b833f7520e2f16f320\windbg_cached.obj icl @"bin.v2\libs\stacktrace\build\07984f9e4da2f3b833f7520e2f16f320\windbg_cached.obj.rsp" windbg_cached.cpp .\boost/stacktrace/detail/collect_unwind.ipp(17): catastrophic error: cannot open source file "unwind.h" #include <unwind.h> ^ compilation aborted for libs\stacktrace\build\..\src\windbg_cached.cpp (code 4) Environment: Windows 2016 Server + MSVS2017 + Intel Compiler 17.0 or later I would like to suggested the following patch: --- 1/boost_1_65_0/boost/stacktrace/safe_dump_to.hpp 2017-08-16 13:37:10.003950000 +0300 +++ 2/boost_1_65_0/boost/stacktrace/safe_dump_to.hpp 2017-08-16 13:38:05.470305000 +0300 @@ -203,7 +203,7 @@ # else # include <boost/stacktrace/detail/safe_dump_posix.ipp> # endif -# if defined(BOOST_MSVC) +# if defined(BOOST_MSVC) || defined(BOOST_INTEL) # include <boost/stacktrace/detail/collect_msvc.ipp> # else # include <boost/stacktrace/detail/collect_unwind.ipp> Thank you in advance. -- Regards, Vasiliy -------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

3 3

Boost 1.65.0 Release Candidate 3
by Marshall Clow 17 Aug '17

17 Aug '17

The third (and hopefully final) release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ [ Note: The RC1s and RC2s are in that directory, too - make sure you get the right files! ] Changes since RC2: * Fix a crashing bug in Boost.ASIO * Fix a compilation error when including both <boost/math_fwd.hpp> <boost/math/common_factor_ct.hpp> * An update to Boost.Spirit to fix compilation errors on Mac OS with -std=c++17 Changes since RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17 The SHA256 checksums are as follows: 1d844a958656e76b140292ec1cbfe770d9916166c16e13b59d3dac1df3b7ef40 boost_1_65_0_rc3.7z 3fc2877cf5da4bbb0c91eab058d2e6764155e705e9c3e2dce2a0248936079675 boost_1_65_0_rc3.tar.bz2 e065b53d7f5326cc20d246b518facedb4407391aaf9fd4a1c90001e0c85accab boost_1_65_0_rc3.tar.gz 96b2ba69c6045060d1dfe012218457870200c2c22af60eb855bab5ffb75c13a2 boost_1_65_0_rc3.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. Thanks! -- The release managers

9 12

Where we are 1.65.0
by Marshall Clow 16 Aug '17

16 Aug '17

RC1 came out on Monday, and it had some problems. Specifically: * Some libraries didn't build with ToT clang/libc++ (Locale, Wave and Test) This is because in C++17, some deprecated library features have been removed. [bind1st, mem_fun, auto_ptr, random_shuffle, etc ] Boost.Config has support for these removals, but this was ... incomplete. [ This is on me; I did the partial job of adding these to Config's libc++ support a while back ] Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and so we can put this off until 1.66.0". But both clang 5 and C++17 are imminent (they will both happen well before the 1.66 release, and so I think we should fix this now. Also, a future version of MSVC will have the same library issues. So I have committed a fix for Boost.Config that fixes the Boost.Test issues. Hartmut has fixed most of the Boost.Wave issues. Artymom has a fix for Boost.Locale. Windows/MSVC builds look good across the board. * Boost.Fiber fails to build on Mac OS with anything other than -std=c++03. There is a fix in develop for this; but there's still a bunch of tests failing. * There's a problem from the beta in Boost.Math. The regression regarding boost/math/common_factor_ct.hpp (vs > math_fwd.hpp) seems to be still there. (For details please see the > original mail and replies: > https://lists.boost.org/Archives/boost/2017/07/237452.php) > What I presume is the fix (https://github.com/boostorg/math/pull/75) was > merged into develop about 12 hours ago, some automatic CI tests still > running. * There's a problem with ScopeExit and Visual C++ 2017 With Visual C++ 2017 and /permissive-, ScopeExit is still broken, for which > there's an open PR: > https://github.com/boostorg/scope_exit/pull/3 > Looks good otherwise on MSVC 14.11, tested with /std=cpplatest and > _HAS_AUTO_PTR_ETC=1, targeting Windows 10 and XP, 32 bit and 64 bit, built > as static libraries. >

12 22

base64?
by Greger 16 Aug '17

16 Aug '17

Hi Is anyone interested in a base64 encode/decode library (for boost)? ty Greger

9 15

Re: [boost] : [math] Enable move semantics for polynomials
by Brian Wood 16 Aug '17

16 Aug '17

Lakshay Garg writes: >Hello all > >The polynomial class in boost.math does not support move sematics. I tried > to implement them and found that they immediately lead to significant >improvements in performance (benchmarking using google-benchmark). > > I would like to get the changes merged into the main repository. I > understand that boost accepts very high quality C++ code Hmm. Here's a benchmark where Boost doesn't do well: https://github.com/thekvs/cpp-serializers . Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 2

RC2 / VS2017 - shared libraries questions
by Raffi Enficiaud 15 Aug '17

15 Aug '17

Hi all, I am still trying RC2 (I think this is the same with RC3). I compile the RCs for VC 2017 (community 2017, v15.2) and the build generates shared libraries that link to the same VC runtime (as reported by dependency walker): Example: Boost atomic: direct link to c:\windows\system32\VCRUNTIME140.DLL for VC2017 and VC2015. Full logs of dependency walker attached. Here are the options I am passing to VC2015: toolset=msvc-14.0 --layout=versioned --build-type=complete --without-log -j 4 address-model=64 threading=multi runtime-link=shared and the options I am passing to VC2017: toolset=msvc-14.1 --layout=versioned --build-type=complete --without-log -j 4 address-model=64 threading=multi runtime-link=shared What am I doing wrong? Thanks, Raffi

4 4

[git] git config core.safecrlf setting for Windows?
by Beman Dawes 15 Aug '17

15 Aug '17

For Windows, github.com/boostorg/boost/wiki/Getting-Started suggests: git config --global core.autocrlf true But is silent about core.safecrlf. Should we be recommending a setting for core.safecrlf, and if so which one? Thanks, --Beman

3 3

[Root.Ptr] Update (C consultancy -> ISO)
by Phil Bouchard 14 Aug '17

14 Aug '17

Greetings, I just wanted to update everyone that I just made the Root.Ptr repository private: https://github.com/philippeb8/root_ptr This is because I am about to work as a consultant to fix memory leaks in C code and possibly C++98 code later on. When I am done testing Root.Ptr then I will submit it to ISO which is already pre-approved. Thank you, -Phil

7 11

Boost 1.65.0 Release Candidate 2
by Marshall Clow 14 Aug '17

14 Aug '17

The second release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ [ Note: The RC1's are in that directory, too - make sure you get the right files! ] Changes from RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17 The SHA256 checksums are as follows: 786ccb478a82ef526fb8649841d2e863af90d7ea31217bb2e938d87aff06cf23 boost_1_65_0_rc2.7z 83dbc7179271825c55a59c26f30cf9de53bb8b42006d920948bad709f5372af9 boost_1_65_0_rc2.tar.bz2 493cbf33a8837b44f87e3ac8a37ec32b9a0a27b8cdb03eac6237a16027a03809 boost_1_65_0_rc2.tar.gz 40e4ccbd52322f9a8cb6e1829075c810d8aad8851f3efb2b3da7fcff6963e14d boost_1_65_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. Thanks! -- The release managers

6 7

[quickbook] Requiring C++11 features in quickbook
by Daniel James 14 Aug '17

14 Aug '17

Hi, I'm thinking of using some C++11 features in quickbook, will this cause anyone any issues? Based on the support tables, I'm thinking of supporting gcc 4.4, clang 3.4, Visual Studio 2013 and later compilers. I won't use anything that doesn't have wide support (such as expression SFINAE). Please let me know if this will be a problem for you. Daniel

5 8

Boost MSM Parent does not handle event
by Denis Kotov 14 Aug '17

14 Aug '17

Hello Henry, I have faced with interested behavior. When in child *FSM* I emit event it handles only by this *FSM (not proper behaviour)* But if I emit this event from the Parent *FSM* it tries to be handled by all sub-states and then by Parent *FSM (proper behavior from my point of view)* Is it possible to send event from Child State Machine to be handled first of all in all Child states and *FSM*-s and then in Parent *FSM* ? *Thanks,* *Best RegardsDenis Kotov*

1 0

[math] Enable move semantics for polynomials
by Lakshay Garg 14 Aug '17

14 Aug '17

Hello all The polynomial class in boost.math does not support move sematics. I tried to implement them and found that they immediately lead to significant improvements in performance (benchmarking using google-benchmark). I would like to get the changes merged into the main repository. I understand that boost accepts very high quality C++ code and since this will be my first time contributing to boost I am looking forward to assistance from other experienced contributors. Could someone please advise me on how to move forward and get the changes merged. Regards Lakshay

4 8

Posts not appearing on Boost Mailman
by Raffi Enficiaud 14 Aug '17

14 Aug '17

Hi Boost, I have an issue with MailMan: I never use "emails" for posting on the Boost ML, I use news.gmane.org through thunderbird. I can see my posts on news.gmane.org, but I cannot see any of my posts here for instance: https://lists.boost.org/Archives/boost/2017/07/index.php Is this normal? Thanks, Raffi

5 8

Hello World
by Naivedya Bansal 14 Aug '17

14 Aug '17

I am a new comer and would like to become a contributor at Boost. Could you please provide me with relevant links from where to start ad I am feeling entirely lost right now. Thank you, Naivedya Bansal

2 1

CUDA V9 (release candidate) breaks compilation
by Hartmut Kaiser 12 Aug '17

12 Aug '17

All, Apparently CUDA V9 has deprecated/removed the __CUDACC_VER__ macro which is used by Boost, see https://github.com/STEllAR-GROUP/hpx/issues/2815 for details. Should this be fixed before the release? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Switch to CMake -- Analysis
by Thomas Heller 12 Aug '17

12 Aug '17

Hi list, After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations... First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit? Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such. Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote: > [...] our build system has become an impediment for many developers > and users, existing and prospective. Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit. Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors. Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;) All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config). While your add it, improve Boost.Build, maybe it can rise again from its ashes (why did it "fail" in the first place?). Regards, Thomas

27 78

Best Practices for Surviving the Boost Test Gauntlet?
by Vinnie Falco 11 Aug '17

11 Aug '17

Beast won the first battle, but it looks like it is losing the war: <http://www.boost.org/development/tests/develop/developer/beast.html> I've never heard of many of these platforms let alone know how to go about fixing the compile, link, and runtime errors. It seems like deallocate() is not part of some standard library's allocator_traits? Link error on operator delete from Boost.System? A lot of little thing. Is there a document or resource which explains the various peculiarities and idiosyncrasies of these platforms and toolchains that I might have a means of fixing them without actually installing them locally (which is unlikely)? Thanks

6 14

boost_check_library.py: correct handling of header-only libs?
by Vinnie Falco 10 Aug '17

10 Aug '17

This script fails for me: <https://github.com/boostorg/boost/blob/master/status/boost_check_library.py…> Because there is no libs/beast/build. But Beast is header-only and has no src/ directory, is this correct? Apologies for posting to the list, but there is no Issues tab on the boostorg/boost repo. Thanks

3 2

Boost 1.65.0 Release Candidate 1
by Marshall Clow 09 Aug '17

09 Aug '17

The release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ The SHA256 checksums are as follows: 0f1352a7738f24b39b564263b66a8c38bc7d984b57406396400474602e961ad3 boost_1_65_0_rc1.7z c2a022d4d6706668ea94b8e799a76e38929e0e34db884ef451fa9d5db6103238 boost_1_65_0_rc1.tar.bz2 7e84a27276792209d48357a0671348768dbf4dd1d4eadbf01b855274208f148d boost_1_65_0_rc1.tar.gz 537c42771b2351b4ea3eb8e9a13a3423edcd155323d2c14c4606cd23fc22d09f boost_1_65_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. Thanks! -- The release managers

7 12

[filesystem] Pull request needs attention
by Robert Dailey 09 Aug '17

09 Aug '17

I have fixed a crash I found due to static initialization ordering in boost filesystem. I have a proposed fix here: https://github.com/boostorg/filesystem/pull/47 It hasn't gotten any attention yet, so I'm hoping someone can offer some advice and/or merge the PR for me. Thanks in advance.

3 3

Boost UUID Maintainer
by James E. King, III 08 Aug '17

08 Aug '17

Greetings! I'm a long-time boost user and over the years I have posted defects into boost trac for the components I have used. I was reviewing the backlog on boost::uuid and in trac and it needs a bit of grooming. I started submitting some PRs to resolve some of these. Edward D. in the CMT group was reviewing some of them and mentioned that there is no active maintainer for the library, and invited me to introduce myself here. I am currently a committer on the Apache Thrift project and I have 20+ years development experience with C++. I have good experience at backlog grooming, and I am very focused on quality. I believe firmly in testing all code branches, and using coverage tools to prove it. I also assisted the glibc team in getting started with Coverity Scan which helped lead to resolution of 138 defects at last count. My current position is a Software Architect at HPE SimpliVity where I have been for the last ~7 years (I'm easy to find on LinkedIn, hopefully). I live in Westford, MA, USA. Given there is no maintainer for boost::uuid currently, I would like to petition for that responsibility. It is a relatively small library in the portfolio and seems like a good introduction to being a maintainer in such a widely used project. Thanks for your consideration, Jim King

5 7

[stacktrace] 1.65.0 RC1 fails to build for MSYS2/mingw-w64
by Stephan Lavavej 07 Aug '17

07 Aug '17

Hi, I just attempted to build Boost 1.65.0 RC1 with MSYS2/mingw-w64. (My build script for 1.64.0 is available at https://github.com/StephanTLavavej/mingw-distro/blob/6e5976af8c63de93bec761… ; I just had to change the filenames for 1.65.0 RC1.) The stacktrace build failed with: gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o In file included from libs\stacktrace\build\..\src\windbg_cached.cpp:10:0: ./boost/stacktrace/detail/frame_msvc.ipp:167:72: warning: missing terminating ' character # error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. ^ ./boost/stacktrace/detail/frame_msvc.ipp:167:5: error: #error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. # error Your compiler does not support C++11 thread_local storage. It's impossible to build with BOOST_STACKTRACE_USE_WINDBG_CACHED. ^~~~~ In file included from ./boost/detail/winapi/file_management.hpp:17:0, from ./boost/stacktrace/detail/safe_dump_win.ipp:20, from ./boost/stacktrace/safe_dump_to.hpp:206, from ./boost/stacktrace/frame.hpp:20, from ./boost/stacktrace/detail/frame_msvc.ipp:15, from libs\stacktrace\build\..\src\windbg_cached.cpp:10: ./boost/detail/winapi/overlapped.hpp:39:9: warning: ISO C++ prohibits anonymous structs [-Wpedantic] }; ^ "g++" -O3 -finline-functions -Wno-inline -Wall -pedantic -mthreads -m64 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o" "libs\stacktrace\build\..\src\windbg_cached.cpp" ...failed gcc.compile.c++ bin.v2\libs\stacktrace\build\gcc-mingw-7.1.0\release\link-static\runtime-link-static\threading-multi\windbg_cached.o... It appears that frame_msvc.ipp is intended to work with both MSVC and MinGW, but it's not correctly recognizing mingw-w64 GCC 7.1.0's behavior. This compiler supports thread_local, although it doesn't support C++11's multithreading headers (without the pthreads wrapper, which I don't build). Either this library should correctly detect mingw-w64, or it should be disabled for mingw-w64. Thanks, STL

2 2

[config] detect std::unique_ptr
by Artyom Beilis 07 Aug '17

07 Aug '17

Hello, I'm searching for a macro to detect reliably existence of std::unique_ptr I didn't found one in boost.config Artyom

2 2

[C++ committee] auto_ptr removal in C++17 - request to comittie
by Artyom Beilis 07 Aug '17

07 Aug '17

Hello, If somebody on committee is on this list. I really want to do something to prevent auto_ptr removal. It is exceptionally useful smart pointer in C++2003 and it is needed by the code that needs to be compatible for both 2003 and 2017. It is needed by libraries that aim to be compatible with C++2003. In the real world there is a huge codebase that uses C++2003 why to break something that works - especially since it works quite well. It isn't "gets" that can't be used securely. C++ committee please stop breaking existing code even if std::unique_ptr much better it does not exist in C++2003. Artyom

3 2

Microsoft vs The Boost License
by Phil Bouchard 06 Aug '17

06 Aug '17

Hi, Just to put everybody in context: 1) Microsoft had invested into Corel so that they get rid of Corel Linux back in 2000 when I was working there: https://www.forbes.com/2000/10/03/1003corel.html 2) Microsoft once again copied my Fornux PowerCalc after I had presented it to them using some web interface: http://www.fornux.com/ With their Microsoft PowerToys: https://en.wikipedia.org/wiki/Microsoft_PowerToys#Included_applications 3) And now here I am with Microsoft trying to copy the idea behind root_ptr's node_proxy: https://github.com/philippeb8/root_ptr With their "deferred_ptr heap": https://github.com/hsutter/gcpp So for some reason I do not trust Microsoft. And I was wondering if the Boost license protects us from an idea behind a library we wrote. Otherwise this makes the Boost license not very useful. Thanks a lot for your help! -Phil

9 20

[BB++] Documentary - Take 3
by Phil Bouchard 06 Aug '17

06 Aug '17

In the following video, I am explaining how objects of a lower scope are being promoted to a higher scope (please fast forward to 10:15): https://youtu.be/OBnpFUVEVe4 I added 5 slides explaining how objects are being promoted and I've renarrated everything after 6:21. I'm keeping the beginning because I am targeting newbies on the subject as well. I hope that's a good explanation because sharing this information publicly is a point of no return for me. Sincerely, -Phil

1 0

Submodule name mismatches between master and develop
by Peter Dimov 05 Aug '17

05 Aug '17

Several submodules have different names on master and develop: - compute (libs/compute on develop) - couroutine2 (libs/coroutine2 on develop) - dll (libs/dll on develop) - qvm (libs/qvm on develop) - vmd (libs/vmd on develop) Should we normalize the names on develop? I think that after fixing .gitmodules, these submodules will appear as-if deinitialized, and would need a `git submodule update --init` to reappear under the new names. There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.

6 8

LIB CSV
by Greger 05 Aug '17

05 Aug '17

During some time I have created this CSV library: <a href="http://www.multi.fi/~ghaga/libcsv/html/index.html">http://www.multi.fi/~ghaga/libcsv/html/index.html</a> (For processing of CSV tables) any use?good?bad? ty G

3 3

[locale] reporting MSVC issue
by Artyom Beilis 04 Aug '17

04 Aug '17

I noticed some failures in Boost.Locale using std backend and narrowed it down to broken Japanese_Japan.932 support of codecvt facet. I tried to report it on https://connect.microsoft.com/VisualStudio but it shown me " You are not authorized to submit the feedback for this connection. " How can I report the bug to Mircrosoft? Thank You, Artyom Below is the sample to reporoduce the issue: Works ok on MSVC 10 and below Fails on MSVC2017 - and it should work ---------------------- #include <iostream> #include <locale> #include <fstream> int main() { { // Japan in Shift JIS/cp932 char const *japan_932 = "\x93\xfa\x96\x7b"; std::ofstream f("testi.txt"); f<<japan_932; f.close(); } try { std::wfstream test; test.imbue(std::locale("Japanese_Japan.932")); test.open("testi.txt"); // Japan in Unicode std::wstring cmp = L"\u65e5\u672c"; std::wstring ref; test >> ref; if(ref != cmp) { std::cout << "FAIL" << std::endl; std::cout << "REF" << std::endl; for(size_t i=0;i<ref.size();i++) std::cout <<std::hex<< unsigned(ref[i]) << std::endl; std::cout << "EXP" << std::endl; for(size_t i=0;i<cmp.size();i++) std::cout <<std::hex<< unsigned(cmp[i]) << std::endl; } else { std::cout << "OK" << std::endl; } } catch(std::exception const &e) { std::cout << "No Locale: " << e.what() << std::endl; } }

2 1

libs/sync?
by Peter Dimov 04 Aug '17

04 Aug '17

We have a submodule libs/sync on the develop branch that isn't on master. What's its fate? Is it going to become a released library at some point, or should we remove it?

2 3

Bjarne's talk on C++20
by Phil Bouchard 04 Aug '17

04 Aug '17

I won't be able to go myself unfortunately but I'm just passing the word: http://www.technomontreal.com/en/news-center/events/bjarne-s-talk-upcoming-… Regards, -Phil

1 0

[release-tools] Doxygen 1.8.6 is rather old
by Vinnie Falco 03 Aug '17

03 Aug '17

Would it be possible to use the newest doxygen instead of the default 1.8.6 for Trusty? The latest version is 1.8.13, and Beast needs a newer version in order to generate correct output. <https://github.com/boostorg/release-tools/issues/4> Thanks

1 0

[BB++] Consensus
by Phil Bouchard 03 Aug '17

03 Aug '17

After the feedback I got back from the community, people agree they would rather improve C++ than seeing a new language taking off. I definitely agree but I would like professional opinions on how the following could be achieved: - to add instances of an object implicitly as each scope; - to add implicit references to these objects in top-level classes - to overload 'operator .' - to use 'auto' for member variables instead of 'decltype' Thanks for your help I really appreciate. Sincerely, -Phil

2 4

[review][mp11] Review report
by Bjorn Reese 03 Aug '17

03 Aug '17

I. VERDICT Mp11 is accepted unconditionally into Boost. There were 14 accept votes and 1 conditional accept vote. See list at end of this report. II. DESIGN Reviewers evaluated the design as very good. Many agreed with the design principle of using template aliases on type lists, which means that Mp11 can be used on std, boost, and custom type lists. Integration with MPL was discussed. This resulted in a new header file <boost/mp11/mpl.hpp> that enables the conversion between mp_list (and std::tuple) and MPL sequences. A version of mp_eval_if that can apply a metafunction to type lists in both the true and false branch was requested. This is not possible due to C++ limitations (template parameter pack must be at the end.) Instead two alternatives were suggested: (1) use a nested mp_eval_if in the true branch, or (2) use mp_if<>::type with mp_defer in both branches. Extra metafunctions were added for working with map and sets: mp_is_set, mp_is_map, and mp_map_keys which returns a list of all keys. No review without a discussion about names. The mp_ prefix received most comments. The prefix is used to avoid collision between mp11 names and C++ keywords. The argument against the mp_ prefix was that MPL and other Boost libraries already have established trailing underscore as the naming convention. The argument in favor is that the mp_ prefix is better suited for later C++ standardization. Other names that deviate from MPL, such as apply versus fn, were also pointed out, and the names of tuple operations were also discussed. III. IMPLEMENTATION The reviewers who looked at the implementation were generally pleased with its quality and simplicity. A faster version of mp_find was proposed during review. On reviewer pointed out that const lists causes obscure compilation errors. IV. DOCUMENTATION The evaluation of the documentation was more mixed. Some found it good, while others found it too terse. A recurring comment was that the documentation is missing beginner-level explanations and examples. For instance, the tuple_cat example was mentioned as being too advanced for an introduction. More examples with higher-order metafunctions (e.g. mp_bind) was requested. The reference documentation does not state the pre-conditions of the metafunctions. For example, what happens when indices are out of bounds? The description of map (list of lists) lead to confusion. Mp11 map entries have one unique key-type, and zero or more value-types. The ability to have multiple value-types per key-type makes it possible to emulate multi-maps. Some where unsure whether C++11 or C++14 was required for the library. There were plenty of other useful comments that I will omit from the review report for the sake of brevity. V. USEFULNESS The library was generally deemed useful. It was discussed if C++11 (and later) makes it too easy to write our own metaprogramming utilities, and thus not needing a metaprogramming library. This was not directed at Mp11 in particular. Some of the arguments in favor of a metaprogramming library were better performance and portability. I would like to add another advantage of a metaprogramming library, namely that it gives us a common vocabulary. VI. CONCLUSION The library fulfills the quality and usefulness criteria without major outstanding issues. The library is therefore cleared to be included into Boost. My main recommendation as review manager is to make the documentation more beginner-friendly before the library is added to Boost. This is a recommendation, not a requirement. VII. PARTICIPANTS The following formal reviews were posted: * Barrett Adair : Accept * Brook Milligan : Accept * Edward Diener : Accept * Glen Fernandes : Accept * Jason Rice : Accept * Joaquin M López Muñoz : Conditional accept * John P Fletcher : Accept * Lee Clagett : Accept * Paul Fultz : Accept * Peter Koch Larsen : Accept * Robert Ramey : Accept * Roberto Hinz : Accept * Vijayan : Accept * Vinnie Falco : Accept * Zach Laine : Accept I would like to thank all participants for their efforts. I would also like to thank Peter Dimov for bringing such a high-quality library to Boost.

3 2

Warning generated by boost::process code
by Wilfred Smith 02 Aug '17

02 Aug '17

Dear Sir or Madam, In Boost 1.64.0, include/boost/process/detail/posix/wait_group.hpp:131:10: warning: unused variable 'start' [-Wunused-variable] auto start = std::chrono::system_clock::now(); ^ /usr/local/include/boost/process/detail/posix/wait_group.hpp:165:10: warning: unused variable 'start' [-Wunused-variable] auto start = std::chrono::system_clock::now(); ^ I believe these two lines should be removed. This appears to be a “copy and paste” issue. The two routines above these lines use the “start” variable to calculate a relative time. However, the later two routines use an absolute time, and the compiler complains as shown above. Removing these two lines should fix the compiler warning and have no adverse effect. Please let me know if this is the wrong place to complain about issues. \W/

2 1

Boost::Process is broken
by Wilfred Smith 02 Aug '17

02 Aug '17

All, Has anyone tried to build with <boost/process.hpp> included using XCode 9.0? I don’t think this went through code review. include/boost/process/exception.hpp:22:30: error: using declaration cannot refer to a constructor using std::system_error::system_error; ~~~~~~~~~~~~~~~~~~~^ I’m not sure that does what was intended, and the compiler thinks it’s silly talk… Any and all assistance appreciated in advance… \W/

2 1

Reminder: Boost Master branch will close for the 1.65.0 release on Wednesday
by Marshall Clow 02 Aug '17

02 Aug '17

Get your bug fixes and documentation updates in now! -- Mashall Upcoming release schedule: 2-Aug: Release closed for all changes, except by permission of a release manager. 5-Aug: Boost 1.65.0 closed for all changes 9-Aug: Boost 1.65.0 release

7 20

[numeric_conversion] Compilation errors with msvc-14.1 and std:c++latest in master branch
by Adam Wulkiewicz 02 Aug '17

02 Aug '17

Hi, I noticed there are compilation errors in master branch and not in develop branch. Only runs with cxxflags= std:c++latest are failing. See e.g.: http://www.boost.org/development/tests/master/developer/output/teeks99-09-q… Affecting Geometry: http://www.boost.org/development/tests/master/developer/output/teeks99-09-q… Regards, Adam

1 0

[release-1.65] changes in master
by Oliver Kowalke 01 Aug '17

01 Aug '17

Will commits that have been added to branch master in the last days be included into release 1.65? ty, Oliver

2 1

[BB++] 17 minutes long documentary
by Phil Bouchard 01 Aug '17

01 Aug '17

Like I promised, here's a 17 minutes long documentary on BB++ which now shows its internals: https://youtu.be/GrNDYWyasxg Regards, -Phil

3 3

[outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0
by Niall Douglas 31 Jul '17

31 Jul '17

For boost-dev's information: https://www.reddit.com/r/cpp/comments/6qo1m3/outcome_v2_has_reached_stabili… --- cut -- I am pleased to announce that Outcome v2, rewritten to fulfil the Boost peer review feedback from May and only reaching feature completeness three weeks ago, has been successfully deployed into two complex libraries which were heavily using Outcome v1. Lots of bug fixes and maturity has resulted, and if you were holding off on deploying Outcome into your own code until now, now is the time! The code itself is now ready for a second Boost peer review, it has all the same testing that v1 had, and I am highly confident as to its quality. What solely remains before Outcome v2 can reenter the Boost peer review queue for a second review is the documentation which remains parlous (and any help with it is greatly appreciated!), and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission. I am also going to have to fix a number of bugs in Standardese the documentation tool first, it currently segfaults when fed the Outcome headers :). @foonathan's tool shows lots of promise, it does far better with C++ 17 than doxygen, just need to shave off some rough edges in the tool. What comes before that though is writing a WG21 paper P0762R0 summarising the Boost peer review which led to the stripped down, barebones v2 `result<T, E>` design and the rationale for the design deviations from `expected<T, E>` as according to the Boost peer review feedback. If WG21 feel warm feelings about a `std::result<T, E>` after reading P0762R0, then I will prepare a formal standardisation proposal for the Library Evolution Working Group (LEWG) and get the ball rolling for standardisation by attending meetings from 2018 onwards until it's through. I'll announce any draft D0762R0 here when it's ready for people to comment and give feedback on soon. My thanks to everyone here on Reddit, on boost-dev, on SG14 low latency, and privately who have helped out with testing, documentation, and so much more in making this library happen. I know those coming from Rust-land feel amazement how long it has taken C++ to replicate Rust's `Result<T, E>`, but I'm very sure ours is enormously superior to theirs already simply by doing so much less because it doesn't need to. Taking time to get design **right** is one of the big things which continues to separate C++ from the upstart systems programming languages. Long may it continue! --- context --- Outcome provides a C++ 14 STL-quality `result<T, EC>` and an `outcome<T, EC, E>` implementation of success|failure value transports, and is expected to pass a second Boost peer review and be submitted for C++ standardisation as the lowest level of an overall framework as proposed by: - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r0.pdf C++ Monadic interface - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r2.pdf A proposal to add a utility class to represent expected object (Revision 4) The idea is that result/outcome are the extremely lightweight struct-like success|failure value transports suitable for usage in public APIs, whereas expected is the much richer variant-like monadic success|failure value transports, and everything participates together under P0650R0. Outcome is a pure header only library with no dependencies. It works best with C++ 17 and Concepts enabled, but can work with C++ 14 on these compilers or better: - clang 4.0 (5.0 required for Windows) - GCC 7 (VS2017 Update 3 RTM is supposed to work too according to Microsoft, my thanks to them for swiftly fixing the several ICEs I reported) Github: https://github.com/ned14/outcome Docs (highly incomplete): https://ned14.github.io/outcome/ Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 4

Boost 1.65.0 Beta 1
by Marshall Clow 31 Jul '17

31 Jul '17

Boost release 1.65.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/> The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1.zip Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 8

[Boost] file transfer
by vikram.smvdu 31 Jul '17

31 Jul '17

I recently started learning asio. Documentation is very awesome. I am planing to make a server where there is a file base. And client can login or connect and access the file.. is this possible. I am unable to send data from client to server.. server can sent but vise versa is not implemented by me.. i am trying.. if any body can point me a direction.. it will be much helpful Thank you Regards V Sent from Samsung Mobile

2 1

[BB++] 5 minutes long documentary
by Phil Bouchard 31 Jul '17

31 Jul '17

Like I promised, here's a 5 minutes long documentary on BB++: https://youtu.be/vXmddU_FS30 Regards, -Phil

2 3

CMake and Boost Build tests
by Edward Diener 31 Jul '17

31 Jul '17

Following John Maddock's appeal for practical solutions related to the move to CMake, I would like to know what the CMake equivalent is to the Boost Build unit test functionality. In other words what do I write for CMake in order to do a Boost Build compile, compile-fail, link, link-fail, run, and run-fail unit tests ? Does CMake have an equivalent to the Boost Build alias rule ? or the Boost Build project rule ? The great majority of the Boost libraries are header-only libraries where Boost Build is used to run the unit tests and, optionally, Boost Build is used to build the documentation using a quickbook, boostbook, doxygen toolset to generate html and pdf files. While I realize that building a Boost library, and making that built library available to end-users via CMake, has been the focus of most of the discussion so far regarding CMake and Boost, I am assuming the move to CMake also means that running unit tests and building docs where applicable must also be done through CMake. If I am wrong about this then I personally will be only too happy to continue using Boost Build to do these things.

14 47

[GitHub] Can boostorg/do-not-use be safely deleted?
by Louis Dionne 31 Jul '17

31 Jul '17

We have this repository: https://github.com/boostorg/do-not-use. The description says Permissions experiments; will disappear without notice. I'd like to confirm that this can safely be removed before I go do it. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/GitHub-Can-boostorg-do-not-use-be-safely… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 4

Dependency report
by Peter Dimov 31 Jul '17

31 Jul '17

I haven't run one of these in a while, so here it is. http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html We have one "supermodule" at level 5 and another at level 13.

7 33

Boost tests with cmake
by paul 30 Jul '17

30 Jul '17

Hi, So, I have made a small demo setting up the tests with cmake, here: https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test-demo This builds and tests the libraries for Boost.System, so it includes: * assert * config * core * predef * static_assert * system * winapi There are no tests for winapi right now, because I don't have a windows machine to test on(but I suppose I could've tested with mingw). This uses the BCM modules to provide common functionality for building and tests. All the tests are setup to run through CTest, and some targets are provided for building the tests. A `tests` target will build(but not run) all the tests. The `check` target will build and run all tests. Since we do want to filter tests by library, all tests are added with the label of the project name(which can be filtered with `ctest -L <label>`). Furthermore there are targets `tests-<project-name>` and `check-<project- name>` that will build and test a single project respectively. So if we are only interested in the tests for `boost_assert` we can run: cmake --build . --target check-boost_assert And this will build and test `boost_assert`. Any feedback will be useful as we move forward on adding the rest of the tests to cmake. Paul

7 20

boost::asio::async_read loops infinite with zero byte of received data
by Shailendra kumar 30 Jul '17

30 Jul '17

Hi, I am new to this community, hope I am not breaking any rule by this mail. I am facing some issue using asio async_read . Please help. I am sharing the link of the question shared at stackoverflow. https://stackoverflow.com/q/45358908/5649379 Please help Thanks Shailendra kumar

2 1

How to resolve connection via route in proxy server?
by jupiter 30 Jul '17

30 Jul '17

Hi, I can use boost to query and to resolve TCP connection from a remote server which has a public IP address: boost::asio::ip::tcp::resolver::query query(host, port); resolver.async_resolve(query, boost::bind(&ConnectionClient::handleResolve, this, boost::asio::placeholders::error, boost::asio::placeholders::iterator)); But how can I connect to the remote server which does not have a public IP address, I have to connect it via route from a proxy server public IP address? Thank you. Kind regards.

1 0

Re: [boost] Boost tests with cmake
by Rene Rivera 29 Jul '17

29 Jul '17

Accidentally replied to the wrong target.. Putting it back on dev list.. On Fri, Jul 28, 2017 at 11:27 PM, P F <pfultz2(a)yahoo.com> wrote: > > On Jul 28, 2017, at 11:22 PM, Rene Rivera <grafikrobot(a)gmail.com> wrote: > > On Fri, Jul 28, 2017 at 11:01 PM, P F <pfultz2(a)yahoo.com> wrote: > >> >> > On Jul 28, 2017, at 7:25 PM, Rene Rivera via Boost < >> boost(a)lists.boost.org> wrote: >> > >> > The predef script is incorrect. This < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/CMakeLists.txt#L25> >> > is not equivalent to the original < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/build.jam#L60>. >> > As the "-DCHECK_VALUE=true" is not passed to compiler in response to the >> > evaluation of '"BOOST_COMP_CLANG > 0.0.0" "BOOST_OS_LINUX == 0"'. It >> needs >> > to try to compile and run one of the programs from here < >> > https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test- >> demo/libs/predef/tools/check>. >> > The test is verifying that both this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef.jam> >> > and this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef_check.h> >> > work as expected. For cmake you would need still need to test the >> latter, >> > still. >> >> Yes, I need to add a custom function `predef_check` in cmake to support >> this, > > > Right. > > >> although it would be best to do the detection directly in cmake rather >> than through the running the tool > > > Not sure what you mean by that. > > > Because when cross compiling you can’t always run the executable, and > using a host compiler seems it would be give different results than the > target compiler. However, a preprocessor expression can be evaluated > through cmake’s try compile, which will safely work with cross compiling. > Perhaps this is what bjam’s rule does already. > Sorry.. I misspoke. They are compile checks, not run checks. If the compile succeeds (of one of the "predef_check_cc_as_*.*") it needs to add the "-DCHECK_VALUE=true" to the compile and run of "check_value.cpp". But the test data in this case would also need to change if you are going to use a try-compile target. As the b2 code parses out those strings and reformulates them as a -DCHECK=.. compile option. -- -- 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

[concurrent] Fast, lock-based queue implementation
by David Stone 29 Jul '17

29 Jul '17

I have written a new concurrent queue that has a focus on high throughput. You can check it out here: https://github.com/davidstone/concurrent-queue Some highlights of this queue: * The bulk interface is faster than other queues for many common load patterns * Almost any element type is supported with very few requirements * Supports any number of producers * Supports any number of consumers (although it works best with only one) * Can dynamically grow and shrink in memory as needed * The interface allows for very little undefined behavior: for the most part, as long as your special member functions like move constructors do not reference the queue you are inserting into, you are fine * Interface based on the pattern of moving values in and returning values via return, rather than other queues which use reference output parameters * Header-only * Design should be fairly straightforward to verify for correctness * Compiles warning free with a very high warning level on gcc and clang * Does not have any errors under ubsan, asan, or tsan I would like to submit this for inclusion in Boost if people find it interesting and useful, but first I would like to get some feedback on the design, implementation, documentation, tests, etc. I have tested this exact version on Gentoo Linux under clang 4.0 and gcc 6.3.0. I will be testing out Visual Studio 2015 and 2017 in the near future to ensure there have not been any regressions. I have run fundamentally the same queue on Visual Studio 2012 (no longer supported due to C++14 features), Visual Studio 2015 (Windows Server 2008 R2, Windows Server 2012), gcc 4.9.1 (Red Hat 6 under developer toolset 3), gcc 4.9.2 (Red Hat 7), and clang 3.9.0 (Red Hat 7) for several years now with no issues, so it is a fairly mature design.

2 4

Documentation snapshot not cycling
by Joaquin M López Muñoz 28 Jul '17

28 Jul '17

Hi, Looks like the documentation snapshot for develop http://www.boost.org/doc/libs/develop/ was last updated five days ago. Any chance this can be given a rebuild? Thank you, Joaquín M López Muñoz

3 3

[optional] Suggestion for adding an optional_number class
by Viktor Sehr 28 Jul '17

28 Jul '17

I'd like to make a suggestion for adding an optional class for number types, called optional_number, where the max value of the number type is utilized as the uninitalized value. Differences compared to std::optional<int, float, enum etc>: *- No size overhead from the wrapped type* - Theoretically faster (althrough in practice probably negilble) - Can be assigned to any value except the max value - Operator-> is removed as it does not make sense for an integer Notes: - Throws if assigned the numeric_limits<T>::max - Also works with enums, using the underlying_type - The operator bool conversion is missing in the prototype implementation Attaching a prototype implementation (currently for C++14). /Viktor

5 8

Proposal for moving Boost to CMake
by David Sankel 27 Jul '17

27 Jul '17

Howdy all, This is a request for comments on a possible path for migrating Boost's build system to CMake. I am not speaking for the Boost Program Committee here, but I plan on bringing this up with them after getting feedback. The motivation is simple. CMake is currently the dominant player in the area of open-source, cross-platform, C++ build-systems. I make this claim based on Google trends graphs and discussions with others at the conferences I attend (CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and usable out-of-the-box with CMake, we would significantly lower the barriers to entry for both Boost users and new Boost developers. Boost serves the greater C++ community and making Boost more accessible would be of great utility. * To ease the migration path, both Boost.Build (the current jam-based build system) and CMake will be supported for a time. * Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build. * The built Boost **binaries** would also provide a compatible, drop-in replacement for the 'FindBoost' module distributed with CMake. The behavior is similar to the previous bullet, except the built binaries would be used instead of the source code. * The style of the 'CMakeLists.txt' files would follow current best practice. We'd resist the temptation to write macros which replace the core CMake functions. There would be repetition in the files, to be sure, but I think we should avoid attempting to innovate CMake. I've seen this fail on many occasions and would like to keep our goal focused, at this point, on migrating Boost to CMake. In the future we could revisit this. * There would be a list of CMake guidelines that we'd use. * Boost libraries should be buildable in isolation and use 'find_package(Boost...)' to discover their Boost dependencies. * We would work with CMake towards eventually taking over maintenance of the FindBoost module distributed with CMake. I see this progressing with several milestones. 1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution and all the 'FindBoost' functionality mentioned above would be incorporated. 2. The unit tests for all Boost libraries are incorporated into CTest (the CMake unit test orchestration tools). 3. The Boost infrastructure is modified to use CTest for unit testing. 4. Unit testing functionality is removed from Boost.Build. 5. Boost.Build is removed. Although there are many other great ideas floating around (e.g. modularization of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on CMakification of Boost because I think it is something that would have big impact and is small enough to be doable. One question that is going to come up is "who is going to do all this work?". Once we decide on a direction, I don't foresee a problem making this happen. Between volunteers, the importance this project has for companies, and the Steering Committee reserves, we should have the resources necessary. Another concern is that some authors may resist. Authors have a lot of leeway when it comes to how they maintain their libraries, what conventions they use, and backwards compatibility concerns. However, there are some things that authors need to conform to, such as our current Boost.Build build and testing infrastructure. I liken this to the development of a city: building developers can make their buildings however they want, but the streets, which control transit between buildings, are centrally regulated. Thanks for your consideration. -- David Sankel

29 140

PGI C++ compiler support
by David Olsen 27 Jul '17

27 Jul '17

Many years ago, Boost was configured to work well with the PGI C++ compiler (http://www.pgroup.com/) But maintenance of the PGI support within Boost stopped about five years ago, and PGI will no longer build Boost without modifications to the Boost sources. I am working on restoring support for the PGI C++ compiler. Many PGI customers want to use Boost, so we at PGI are putting in the effort to make that easy to do. I have already fixed a bunch of bugs in the PGI compiler that were triggered by Boost code. Now it is time to make necessary adjustments to the Boost source. I have created six pull requests that make it possible to build Boost with PGI. https://github.com/boostorg/build/pull/218 https://github.com/boostorg/filesystem/pull/49 https://github.com/boostorg/mpl/pull/30 https://github.com/boostorg/spirit/pull/236 https://github.com/boostorg/type_traits/pull/45 https://github.com/boostorg/config/pull/169 The only big change is overhauling the pgi.jam file. The other changes are just removing an obsolete #if or changing an #if expression. None of the changes should affect any compiler other than PGI. Next I am planning to make any necessary changes to test code and to header-only libraries so that PGI gets decent results when running the Boost tests. Then I will look into setting up a test bot for the PGI compiler here at PGI. -- David Olsen (dolsen(a)nvidia.com) NVIDIA - PGI Beaverton, Oregon

5 6

[type_erasure] link to any_cast reference section
by Joaquin M López Muñoz 27 Jul '17

27 Jul '17

Hi, Unlike most classes/functions in Boost.TypeErasure, the following http://www.boost.org/doc/html/boost/type_erasure/any_cast.html does not go to the reference for boost::type_erasure::any_cast, the proper link being http://www.boost.org/doc/html/boost/type_erasure/any_cast_idp758556752.html Problem is this seemingly autogenerated file name is unstable. For instance, for Boost 1.63 the link was http://www.boost.org/doc/libs/1_63_0/doc/html/boost/type_erasure/any_cast_i… in develop it is http://www.boost.org/doc/libs/develop/doc/html/boost/type_erasure/any_cast_… and in master it is http://www.boost.org/doc/libs/master/doc/html/boost/type_erasure/any_cast_i… which makes it impossible to refer to this section of Boost.TypeErasure documentation from other pages. Maybe this can be fixed? Thank you Joaquín M López Muñoz

2 5

[review][mp11] Formal review of Mp11
by Bjorn Reese 27 Jul '17

27 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master Please answer the following questions in your review [4]: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain? [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html [4] http://www.boost.org/community/reviews.html

18 56

[Signals2] library fails to compile with -fno-exceptions
by Jackie Kay 26 Jul '17

26 Jul '17

The signals2 Git repo does not have issues enabled, so I thought I'd ping the list about this. Trying to compile any program that includes boost/signals2 with -fno-exceptions fails as of 1.64: #include <boost/signals2.hpp> // boost/signals2/slot.hpp will also reproduce the error int main() { } g++ prog.cc -I<path to Boost 1.64.0 headers> -std=c++11 -fno-exceptions View it on Wandbox: https://wandbox.org/permlink/vZVpF5bb8E9K7sDz I was also able to reproduce this locally on the develop branch. It appears this is because the slot_base lock function is not defined when exceptions are disabled, but this is not checked when it lock is called in `slot_template.hpp`. I am working on a fix, but I would like to know what the path moving forward for the fix would be. Signals2 is currently unusable in 1.64 with exceptions turned off.

1 0

Separate Boost CMake mailing list
by Edward Diener 25 Jul '17

25 Jul '17

I think that a separate Boost CMake mailing list would be beneficial, rather than have all the discussion about the move to CMake, as the default Boost build system, as well as further uses of CMake with Boost libraries and tools, on the developers mailing list. This is similar to the way that Boost currently has a separate mailing list for Boost Build.

5 8

Mp11 review
by paul 25 Jul '17

25 Jul '17

Hi, this is my review of mp11. Please answer the following questions in your review [4]: > 1. Should Mp11 be accepted into Boost? Please state all conditions > for acceptance explicity. Yes Mp11 should be Accepted. > > 2. What is your evaluation of the design? Very good design overall. I don't know if I really like the `mp_` prefix. Trailing underscores is common in boost, but the mp prefix makes sense for standardization. It uses the `std::integral_constant`, but it might be nice to use another implementation, as that can help make it consistent between C++11 and C++14. Also, providing an integral constant with operators could help improve interoperability with hana-style metaprogramming(which also help interoperate with the Fit library as well). Of course, I don't know if mp11 is right place for it. It seems it would be better to have a separate library for this and the other C+14 features as well. Also why is `mp_with_index` only constexpr on C++14 and higher? > > 3. What is your evaluation of the implementation? The implementation seems to be good and provides competive performance with other metaprogramming libraries, but I do wonder if some of Odin's metaprogramming techniques(such as recursive aliases) can be used to improve the performance as well. > > 4. What is your evaluation of the documentation? Very well documented and organized. > > 5. What is your evaluation of the potential usefulness of the library? I think this library can be very useful for C++11 metaprogramming where I have needed. I don't think it would be as useful for the Fit and Tick library because they still target gcc 4.6, which mp11 doesn't support due to being based around template aliases. > > 6. Did you try to use the library? With what compiler? Did you have > any problems? Yes, I did, and also ran the tests. I tried to run the tests on some configurations that aren't ran in the travis CI(like clang 3.5 with C++14). And all the tests do pass. > > 7. How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I spent a couple hours reviewing, and I have implement ad-hoc versions of these in my own libraries as well. Paul

1 0

[review][mp11] Reminder of ongoing formal review
by Bjorn Reese 25 Jul '17

25 Jul '17

The formal review of Mp11 continues until (and including) Monday, July 24th. There have been four formal reviews so far. I would like to ask the Boost community for two favours: 1. Please postpone the discussions about CMake and the future directions of Boost until the formal review has ended. 2. Please review the Mp11 library instead. If you disagree with any of the above, please contact me off-list. Here is the call for review once more: The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master Please answer the following questions in your review [4]: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain? [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html [4] http://www.boost.org/community/reviews.html

7 12

[review][mp11] Review of Mp11 has ended
by Bjorn Reese 25 Jul '17

25 Jul '17

The review of Mp11 has ended with a total of 12 formal reviews (and one pending.) I would like to thank all who have participated in the review, as well as those who agreed to postpone CMake discussions until the end of the review. The review report will be posted in the near future.

1 0

[config] What Feature is this??
by John Maddock 25 Jul '17

25 Jul '17

Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function. The code I want to enable involves function overloading based on a decltype return type as in: auto integrate(args...) -> decltype(expression1); auto integrate(args...) -> decltype(expression2); where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied). This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called. Alternatively, if anyone has a better way of differentiating between unary and binary functions I'm happy to hear about it ;) Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

6 13

[review][mp11] Formal review of Mp11
by Glen Fernandes 25 Jul '17

25 Jul '17

What follows is my review of the Mp11 library: [Should the library be accepted into Boost?] Yes. I vote for an unconditional ACCEPT. [What is your evaluation of the design?] Excellent. The design where any template can serve as a list, and any template can serve as a meta-function is both elegant and powerful. The additional quoted meta-function support with utilities such as mp_bind, mp_bind_front, and mp_bind_back, addresses the other request I had when reviewing an earlier version of Mp11. While HOMF were never essential, as the article pointed out, users appreciate more ways to one-line things without having to write a helper type. Some additional primitives are desired, as mentioned later in this review (e.g. min and max functionality) but overall the toolkit is already vast and useful. [What is your evaluation of the implementation? Excellent. The focus on performance is definitely appreciated while we still have to depend on libraries for many of these meta-programming primitives. Ideally many of these would be provided in the standard library and have implementations that only a compiler vendor could provide with built in support, and offer performance beyond what a library could offer. In the meanwhile, the performance offered by Mp11 is great, more than sufficient for my needs, and in my opinion also for the majority of users. In comparison, the tiny C++11 meta-programming library that I have implemented, uses only the obvious C++11 implementations for most functionality, and does not offer the same fast compile times as the equivalents in Mp11. The techniques used by Mp11 via C++11 constexpr, C++14 constexpr, and even C++17 fold expressions, besides improving Mp11 performance, were a valuable source to learn from. Suggestion: Can all the workarounds for MSVC versions 1800 and older for the empty list cases be avoided by instead using a helper trait? i.e. template<template<class...> class L, class... T, template<class...> class P> struct mp_find_if_impl<L<T...>, P> { using type = typename mp_find_if_impl_2<P, T...>::type; }; i.e. Introduce mp_find_if_impl_2 which would then have the obvious implementation as before, only without requiring the MSVC workaround? This is only worth considering if you find it to offer some benefit such as: Additional maintainability of the Mp11 code, with less workarounds, and no costs, e.g. no increase in compilation times as a consequence. [What is your evaluation of the documentation? Very good. The reference documentation is clear, and easily understood. More example and tutorial content before the reference section would always be welcome, but not necessary. Suggestion: The two-part article that Peter wrote (which is referenced in the documentation) is in my opinion so valuable for users to gain better understanding and appreciation of the library that it should be included in the library distribution as part of the documentation. Ideally in the same Asciidoc form as the current documentation, as a supplemental document (or Appendix entry). Suggestion: Does it make sense for the documentation to have a section describing the conventions the library uses, for potential contributors as much as users? e.g. If someone was designing an mp_min_element, should it yield the element type result, or the list index size constant result? Is there an established convention of when an error is acceptable for an empty list versus returning an index? Correction: Under heading mp_find_if<L, P>: "mp_find_f<L, P> is an" should be "mp_find_if<L, P> is an". [What is your evaluation of the potential usefulness of the library? Incredibly useful in its current form, and this is only going to increase as the library is extended based on user requests for additional functionality. Almost every meta-programming primitive that I have needed recently either already exists in Mp11, or I am able to implement using Mp11 with a little effort. During this review I replaced the use of my own meta-programming library in a project of mine without any issues. As part of this review I also tried several exercises where I implemented certain traits and meta-functions using Mp11. Of all the exercises that I attempted, the only one where the library lacked the necessary utility was an "mp_min_element" function: This was an implementation of the typical "type_with_alignment" trait, which can easily be implemented using a "min_element" functionality. Mp11 does not have mp_min, mp_max, mp_min_element, mp_max_element presently, and I believe they should be added because they are useful and users will probably find themselves implementing it. Sure, mp_sort exists, but I would not use a sort when a min_element can suffice. In this case, type_with_alignment<N> could use mp_min_element with a predicate that finds the type in an mp_list of several scalar types, that matches has an alignment of at least N and has the smallest size, and then check that the result element type of the mp_min_element is at least N. The litmus test for me for a meta-programming library is the question: Would I use Mp11 in library code? The answer for me is "yes". If it was part of Boost, I would use it in other Boost libraries (that already require C++11 or higher). [Did you try to use the library? With which compiler(s)? Did you have any problems?] Yes. I used the library as a replacement for an existing meta-programming library of mine in real (non-toy, non-exercise) project code that is compiled with g++ 4.8.5 in c++11 mode for x86 and x86_64 Linux, using Boost 1.64.0, on 64-bit RHEL 6 and measured compilation times. I also used the library in a few exercises that I compiled with g++ 7.1 and clang 4.0.0, for x86 and x86_64 Linux, using the current Boost master branch, for c++11 and c++14, on 64-bit Fedora 26, and again measured compilation times. I also compiled and ran the Mp11 unit tests with the compilers, C++ standard modes, architectures, Boost distributions, and operating systems mentioned. [How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?] More than ten hours over this weekend reading the documentation, reviewing the implementation and tests, using Mp11 in a project replacing my own C++11 meta-programming library, using it in various exercises, and running the Mp11 unit tests with the various compilers, C++ standard modes, targets, and Boost distributions listed above. Prior to the preparation for the review, I had spent some time with an earlier version of Mp11 and comparing it to Metal for implementing a few meta-functions, including the "instantiates_" example from my library: instantiates_<T, templates_<std::set, std::multiset, std::unordered_set> > Where instantiates_ should be implemented in terms of "is_instantiation_of_": is_instantiation_of_<T, std::set> Which has the obvious behavior indicated by the trait name. The Mp11 approach provided by Peter for this case, and the relative ease with which I was able to implement the other meta-functions using Mp11 were a convincing demonstration of the usefulness of the library. [Are you knowledgeable about the problem domain?] Like many of us, I had written a meta-programming library as C++11 language features have become available. Before that, if Boost.MPL solved a problem, more often than not it was convenient and useful enough to just use it, even if writing my own implementation would result in faster compilation times. Peter's article, however, opened my eyes to a more elegant design, and changed how I implemented my C++11 meta-programming library, and in general shaped what I think about meta-programming in modern C++. Thank you Peter for your work on Mp11, for submitting it for inclusion in Boost, and for the articles that motivated it and taught the rest of us. Glen

6 5

[BB++] Now fixes all of your memory leak nightmares
by Phil Bouchard 24 Jul '17

24 Jul '17

Greetings, Now I have an example showing off the cyclic reference handling. Please see: https://github.com/philippeb8/root_ptr/blob/bb++/bbpp2cpp/tests/input2.bb This program correctly outputs: Document::Document(const boost::node_proxy&) auto __0(boost::node_proxy&, int) 1 Document::Document(const boost::node_proxy&) Document::~Document() 2 Document::~Document() So I just came to realize we could use this tool to parse entire projects to generate the right C++ code, after having disabled the 'operator delete', and then run the executable, which still is 3.5x faster than Node.JS. For the newcomer please see: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp I am going to present this to NASA and company. Meanwhile anybody is welcome to help me out extending the parser to support template syntaxes. Regards, -Phil http://bbplusplus.com/

4 6

[asio] windows service async server crashes after running for a while; though it works fine from console
by Kyoryu Kurayami 24 Jul '17

24 Jul '17

I have an existing console async server that I converted to a windows service. After running for a while (about 1-2 hours), the service would eventually crash caused by stack overflow on different parts of the code (been trying different approach on the code that causes the stack overflow exception but to no avail as it would still crash on a different location) Now, I have been wondering if an async server approach is really suitable for a windows server or should I then opt to convert it to synchronous instead. I used the combination of *io_service::reset()* and* io_service::run() *to block the current code as I've read somewhere that thread running the *io_service::run()* shouldn't immediately exit if it is running as a windows service. Do note that my previous implementation was just calling the *io_service::run() *on another thread, but this doesn't seem to work as per the explanation and solution mentioned above.

2 1