August 2017 - Boost - lists.boost.org

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

13 Aug '24

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

49 200

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

23 Feb '18

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

4 6

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

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

6 10

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

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

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

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

[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

[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