June 2018 - Boost - lists.preview.boost.org

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

13 Aug '24

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

49 199

[RFC] unique_val (handles, IDs, descriptors...)
by Miguel Ojeda 15 Oct '18

15 Oct '18

Hi all, While working on a medium-sized project, I had to wrap quite some handles, IDs, descriptors, etc. into RAII classes. Somehow, writing those and making them movable seemed more verbose than needed. I searched in the STL and Boost for something already implemented, but nothing seemed to come up. I decided to write my own prototype to see whether I was missing something important; but actually using it in my project felt quite natural and simple. At this point, I asked for a second opinion from a well-known expert (thanks Scott!) and he agreed that it seemed like a reasonable idea but, of course, he would also be surprised if others haven't come up with something similar. So I polished it up a bit and uploaded it to: https://github.com/ojeda/unique_val Below you have the introduction inlined [1]. If you have the time, please take a look (specially to the Rationale) and let me know your comments. The code itself is very short and straightforward. If you already have this class/template in Boost somewhere that I missed, please let me know! Otherwise, if you think this could be interesting to put into Boost in some existing library (not sure which) or as a new tiny library, I would be glad to make the effort to expand it, clean it up, etc. Thank you! Miguel [1] """ A single-header header-only library for representing unique values (handles, IDs, descriptors...) that default to a value on move for C++11, C++14 and C++17. It simplifies writing resource-owning classes (RAII) with move semantics support for resources with handles, IDs or descriptors that are supposed to be used as unique values, not as unique pointers. For instance, it can be used with non-pointer handlers (like the `int` file/socket descriptors in POSIX) and with opaque pointer handlers (like the `HWND` handles in the Win32 API). As such, it can be used as an alternative to `std::unique_ptr` with or without custom deleter, specially for resources that use a non-pointer type or resources that are not simply heap-allocated. It does not have any overhead compared to using the original type. It supports booleans, integers, pointers and enumerations. The default value can be different than the default-constructed value (i.e. different than 0, nullptr, etc.). """

7 13

Original STL Library Documentation has been recovered and is now safe forever.
by Robert Ramey 02 Sep '18

02 Sep '18

The Standard Template Library is the foundation of modern C++. The creation and publication of this code and its documentation set a new standard for the formal specification of what a computer program should do, how it should be designed and how it should be formally documented. These pages were maintained first by Silicon Graphics and then later by Hewett-Packard. In January of 2018 these pages were removed by H-P. This is a historic blunder. I have recovered the original STL Library Document and hosted them here: http://www.rrsd.com/software_development/stl/index.htm Robert Ramey

8 10

Strange libstdc++ versions in travis-ci testers
by Andrzej Krzemienski 15 Aug '18

15 Aug '18

Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers. Whenever I push a new commit I get a number of failures from travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342?utm_source=email&u… Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious? Regards, &rzej;

5 12

Docker environment(s) for Boost Development
by James E. King, III 26 Jul '18

26 Jul '18

I submitted a pull request into the superproject containing some docker scripts. The intention of this is to simplify managing a docker build environment for boost: https://github.com/boostorg/boost/pull/184 I'm wondering if folks will find this useful, and whether folks think this should be in its own submodule instead of being in boostorg/boost. I only have an Ubuntu Bionic environment in this pull request but it wouldn't be that difficult to add debian, centos, and others, as well as various versions of each. I have tested it on Unix and on Windows. On Unix the performance is quite good overall - but on Windows since they use SMB to do the sharing it is really slow (I would say a good 20 times slower between typing "b2" and getting the first output as it scans through all the files. I would recommend continuing to use a virtual machine on Windows Hosts for unix boost development, but this option is there and hopefully they will improve things. This partially came out of the discussion we had a number of months back about how we handle third party dependencies. For the most part one has to look at README files in various locations to learn about them. This is an attempt to pull all the dependencies together for a complete build into one place (the Dockerfile). One day when Microsoft supports Visual Studio compilation inside a reasonably sized windows container (i.e. based on nanoserver and not Windows Server Core), I'd like to add that as well since managing the dependencies on Windows is a bit harder (you usually have to build them). Thanks, Jim

5 8

Looking for help on preparing for review
by Damian Vicino 20 Jul '18

20 Jul '18

Hi, I'm preparing my library safe_float to be proposed for review. The library was born in the GSOC2015, but it never reached a review ready state. My plan is to change that in the next few months. At this point, I'm looking for some volunteers to proof-read the documentation. Code is going through major rewrite, and I will send another mail looking for help with reviewing the code when that is done. The most current documentation can be read directly from the web here: https://sdavtaker.github.io/safefloat/ Any comment is appreciated. Best regards, Damian

5 9

Boost.Signals deprecation and removal
by James E. King, III 15 Jul '18

15 Jul '18

This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release. - Jim

9 9

[Boost.Serialization] Help with PR fixing a memory leak in the current version
by Alexander Grund 12 Jul '18

12 Jul '18

Hi, TLDR: I would like https://github.com/boostorg/serialization/pull/105 to be merged for the next Boost release to fix a memory leak and need someone to review this or help getting it merge-ready. Details: Some time ago I made an analysis of a crash introduced in Boost 1.65.0 in the serialization part. The details are quite complicated as the cause is static initialization/destruction order in shared libraries which may even depend on compilers (could not confirm) or standard libraries (dito, observed in all tested versions). It boils down to a violation of the expected destruction order in the case of shared libraries. I observed how 2 global instances of the same type but from different shared libs are destroyed together although the 2nd should not yet be which causes a use-after-free from another global instance. The Singletons involved did have methods to detect, whether they are active or destroyed but they were kinda optimized away in Boost 1.65 leading to a crash which makes the whole library unusable. Not understanding the root cause of the crash lead to changing the singleton to use dynamic allocation, but not freeing it which leads to the memory leak that is currently in Boost. The current state of the develop-branch changed this back to the crash situation we had before making it unsuitable for the next release. Another pair of eyes would be great to check the PR and get this finally fixed. Thanks, Alex

6 33

python::numpy not built on windows binary installers
by Nicholas Devenish 07 Jul '18

07 Jul '18

Hi All, I just downloaded the windows boost binaries from https://dl.bintray.com/boostorg/release/1.67.0/binaries/, linked from the boost downloads page. They are missing the boost_numpy library. This (silently) doesn't build if the python installation that boost finds is missing numpy. This is listed as "Third Party" so apologies if this is the wrong place to report it - but it's not clear from the page who makes them. I also couldn't find any mention of this, so don't know if it's a deliberate exclusion. Nick

2 3

[MultiIndex] Hinted insertion for multiple indices?
by Gareth.Sylvester-Bradley＠sony.com 04 Jul '18

04 Jul '18

Is there a way to provide insertion hints for multiple indices in a multi_index_container? In a particular example, I have a container with several ordered_non_unique indices, and for the majority of insertions, the value will end up at the end of these indices. I'm looking for a way to provide the index.end() hint for all of these indices? (Or maybe alternatively, to relax the stability/insertion-order guarantee?) Thanks, Gareth

2 3

CMT Library and CI Status for Boost 1.68.0
by James E. King III 01 Jul '18

01 Jul '18

I have been working on adding CI to the CMT libraries (and a few others). This provides improved quality and metrics for each repository with builds for various linux and windows combinations, as well as code coverage and static code analysis with coverity scan. Here is the current status for work that will make it into 1.68.0: The CI framework I have been adding is here: https://github.com/jeking3/boost-ci CI has been enabled on the following repositories (and any identified defects have been resolved) and is passing: function, mpl, pool, property_map, ptr_container, rational, tokenizer In addition, Boost.Move and Boost.Signals2 are also now using this framework to improve deliverable quality. CI not yet enabled on (and reasons): Boost.Assign fails to compile <https://github.com/boostorg/assign/pull/16> with MSVC 2012 in Appveyor. Boost.ConceptCheck fails to compile <https://github.com/boostorg/concept_check/pull/13> on most compilers in Travis CI and Appveyor. (It looks like it's unusable.) Boost.DisjointSets - status unknown (no CI) - open question still unanswered: Can we merge this into container? It is only used by graph and graph_parallel. Boost.DynamicBitset fails to compile <https://github.com/boostorg/dynamic_bitset/pull/23> on all MSVC and on linux with c++03 mode. Boost.Interval (numeric/interval) fails to compile <https://github.com/boostorg/interval/pull/14> - most combinations fail and may go into an infinite loop in some cases. Boost.Logic (tribool) uncovered issue #8 <https://github.com/boostorg/logic/issues/8>. Boost.Signals - we discussed a removal notification in an upcoming release but no action has been taken by the CMT yet to make this happen so it may slip into the next release. Boost.Statechart needs some Jamfile help to get it to work with this CI infrastructure. I am most concerned about Boost.ConceptCheck and Boost.Interval. Both may be unusable at this point. If folks have any spare cycles and care to take a look, it would be appreciated. Thanks, Jim

3 3

[config] MSVC feature-test macros
by Stephan T. Lavavej 29 Jun '18

29 Jun '18

Hi Boost devs, FYI, VS 2017 15.8 Preview 3 has been released, with support for feature-test macros. If you want to take advantage of the feature-test macros, please notify me immediately about any problems so I can get them fixed for the production release. Notes: * __has_cpp_attribute is the one thing that isn't supported yet. * There are minor changes coming for the production release of 15.8, notably L suffixing and an increase in the value for __cpp_deduction_guides. * Library macros are defined by including any <meow> or <cmeow> header (but not <meow.h>). <ciso646> is the lightweight way to get all macros. This will be superseded by <version> in C++20, but that is not yet implemented. * The macros are always provided regardless of the /std compiler option. (Of course their definedness and values vary.) * We are defining __cpp_exceptions and __cpp_rtti, although those weren't picked up for C++20. * The only fundamentally new ability that these macros provide is the ability to sense whether thread-safe statics are supported; this was previously controlled by a compiler option, but not reflected in any MSVC-specific macro. * The macros respect all of our compiler options and library control macros - e.g. if std::byte's definition is suppressed (to avoid conflicts with the Windows SDK), then __cpp_lib_byte reflects that. Hope this helps, STL

6 7

[chrono] #13557 Boost 1.67.0 chrono library Windows build installs NTFS junction
by Stephan T. Lavavej 28 Jun '18

28 Jun '18

Hi Boost.Chrono devs, I have some additional information about https://svn.boost.org/trac10/ticket/13557 . (Also tracked at https://github.com/StephanTLavavej/mingw-distro/issues/58 , it affects both MSVC and MinGW.) As Joshua Morrison discovered, copying libs/chrono/stopwatches/include/boost/chrono/. to boost/chrono before building is a workaround that prevents the junction and hardlink from being created. Also, I mentioned this on Twitter and René Rivera said: "Those links are supposed to appear only for the git checkout of @Boost_Libraries and are created on demand when headers are reference during the header scanning. Creating those for a release is a bug in the release process." (https://twitter.com/grafikrobot/status/1011077139511369728 ) I'm still not sure what the correct fix is, but it seems that boost/chrono should contain the stopwatches files, if they're being referenced by other headers. Thanks, STL

2 2

[ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by ThePhD 28 Jun '18

28 Jun '18

Dear Boost Community, I was encouraged to submit this small library that I had created as a formal public investigation of the performance and API-interop benefits to the Boost Mailing List, to perhaps see if other people have come up with something similar to this at their own comapnies. out_ptr is a small abstraction for making types such as std::unique_ptr, std::shared_ptr, boost::shared_ptr, and the upcoming std::retain_ptr <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html> work work C-Style output functions as a parameter, addressing the need of wanting to be able to do "my_c_api_init( foo, bar, &my_smart_ptr );". It's design is meant to be extensible by both the library implementer and the user, enabling it to be used with other pointer types that do not originate from either `boost::` or `std::`. The library replaces the sought-after syntax of: my_c_api_init( foo, bar, &my_start_ptr ); with a free function that does not impose on the interface of the smart pointer: my_c_api_init( foo, bar, out_ptr( my_smart_ptr ) ); This makes it possible to use a temporary return value to give a reference to a pointer value that then performs a reset on the smart pointer. Is there any want for something like this? I know it has seen use at companies and Studios I have worked in and interacted with, including Microsoft and VMWare. std::retain_ptr's author also has a need for this to make interop easier with reference-counting C APIs and beyond, and I myself implemented something like it 5 years ago and have been using it ever since. Sincerely, JeanHeyd P.S.: this is also going to end up going in the Post-Rapperswil Standards C++ Mailing as well. The proposal is also contained in the repository: https://rawgit.com/ThePhD/out_ptr/master/papers/d1132.html

1 0

[release] 1.68.0 closed for major changes
by Marshall Clow 28 Jun '18

28 Jun '18

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/ history/boost_1_68_0.qbk> After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Thanks, -- The Boost Release Team

1 0

[Boost PP] MSVC PP
by degski 28 Jun '18

28 Jun '18

We seem to be getting there. Visual Studio 2017 version 15.8 Preview 3 Announcement <https://blogs.msdn.microsoft.com/visualstudio/2018/06/26/visual-studio-2017…> tl:dr: "*C++ Standards:* A new, experimental, token-based preprocessor that conforms to C++11 standards (including C99 preprocessor features), enabled with /experimental:preprocessor switch. This will be controlled with macro _ *MSVC*_TRADITIONAL, which will be defined to 1 when using the traditional preprocessor and 0 when using the new experimental standards conformant preprocessor." degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

4 4

[release]
by Zach Laine 27 Jun '18

27 Jun '18

I'm seeing a difference in the Yap Quickbook build in a local checkout of boost-with-submodules, develop branch, and the Circle CI develop build. The auto-index seems to be wrong in the Circle CI one: https://www.boost.org/doc/libs/develop/doc/html/yap.html Note that the stuff at the bottom of that page refers to content in other libs. The Reference section also points to the wrong stuff in the .hpp detail pages. When I originally moved Yap over to Boostorg, I did not initially update all the paths correctly for an integrated Boost build; I was doing a standalone doc build. I have since fixed the paths, and I see the right index and Reference sections when I build locally. I suspect that the Circle CI cache has some files lying around that are causing this problem, but I don't really know. Does anyone have any insight into this problem? Does anyone have admin rights to do a Circle CI rebuild-without-cache? Thanks, Zach

1 0

[Library idea] Type-safe Flagsets
by Julien Vernay 27 Jun '18

27 Jun '18

Hello everybody, I want to know if some people are interested in a type-safe flagsets. I define flagsets as a container similar to a bitset, but where each bit has a meaning. For example, we could have in some game : enum Direction : unsigned { UP = 0b0001, DOWN = 0b0010, LEFT = 0b0100, RIGHT = 0b1000 }; ... unsigned player_dir = UP | RIGHT; if ((player_dir & (UP|LEFT)) == (UP|LEFT)) player.setAnim("up_left"); player_dir &= ~UP; //removing UP from player_dir I think there are some issues with this kind of flagset : - you need to think about power-of-twos when attributing values to your flags. - you need to use bitwise operations which can be non-trivial, even for removing only one flag. - it is not safe: for example with another flagset using the flag INIT_VIDEO (in a window library like SDL), you can do " UP | INIT_VIDEO " even if the two flagsets have nothing in common With a type-safe flagset library, this code would become : namespace Direction { struct UP; struct DOWN; struct LEFT; struct RIGHT; using Type = flagset<unsigned, UP, DOWN, LEFT, RIGHT>; //unsigned is the underlying type }; ... auto player_dir = Direction::Type::Value<Direction::UP, Direction::RIGHT>(); if (player_dir.allOf<Direction::UP,Direction::LEFT>()) player.setAnim("up_left"); player_dir.reset<Direction::UP>(); It is more verbose but also more safe and easy to use. I actually have a partial implementation on GitHub, supporting read, write and conversions to strings : https://github.com/J-Vernay/flagset I would like to know if some people are interested in this kind of library, and if yes, what they think about the current syntax/implementation. Thanks for reading !

3 8

Re: [boost] On Boost's logo copyright
by Mateusz Loskot 25 Jun '18

25 Jun '18

(CC to boost(a)lists.boost.org) On 25 June 2018 at 22:03, Giovanni Mascellani <gio(a)debian.org> wrote: > Il 25/06/2018 14:33, Mateusz Loskot via Boost ha scritto: >> AFAICT, the logo design was established around Boost 1.33. >> Here is related note from the release notes [1] >> >> ``` >> Rene Rivera for the new Boost web page design; and Zoltan >> "cad" Juhasz for the new Boost logo. >> ``` > > This is very useful, thank you! You're welcome. I hope I've pulled the actual facts. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

On Boost's logo copyright
by Giovanni Mascellani 25 Jun '18

25 Jun '18

Dear Boost developers, I am preparing the next upload of Boost package in Debian. I would appreciate your help on a little detail, which is however very important for Debian (if this is not the right place to ask, please accept my apologies and direct me to a more appropriate one): who is the copyright holder of Boost's logo? I understand that it is licensed under the BSL license, but it seems to me that the name of the rights holder is not listed anywhere. Thanks for your help and for the great library, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

2 1

[release][yap] Master archive builds broken.. for a long time.
by Rene Rivera 24 Jun '18

24 Jun '18

While checking to see that the master PRs I did yesterday to master where not causing problems I noticed something unrelated. Looks like the master archive build has been failing for a long time now. Seems the addition of YAP is broken. It appears there's some documentation files missing: /home/ubuntu/build/boost/bin.v2/doc/gcc-4.8/debug/auto-index-on/threadapi-pthread/src/boost.auto_index.docbook:65535: element include: XInclude error : could not load /home/ubuntu/build/boost/bin.v2/doc/gcc-4.8/debug/auto-index-on/threadapi-pthread/home/ubuntu/boost/libs/yap/doc/yap_reference.xml, and no fallback was found >From any of the builds in < https://circleci.com/gh/boostorg/boost/tree/master>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 4

[math] policy<discrete_quantile<real> > test's fail because multiple matches for 'real'
by Brian Kuhl 24 Jun '18

24 Jun '18

When I compile with VxWorks 7/Clang v5/ Dinkum 700 there is an inline real() function in global scope. Leading to a few errors like this: ----------------------------------------------------------------------- clang-vxworks.compile.c++ ../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o "/yow-build40-lx1/bkuhl/vx7/compilers/llvm-5.0.0.3/LINUX386/bin/clang" -x c++ --target=x86_64 -m64 -mcmodel=large -fno-omit-frame-pointer -fno-strict-aliasing -mno-implicit-float -fno-builtin -nostdlibinc -nostdinc++ -fno-use-init-array -ftls-model=local-exec -ansi -std=c++14 -O2 -Wall -Wno-missing-braces -Wreturn-type -Wconversion -Wformat -Wno-sign-conversion -Wno-c++11-narrowing -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/system -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -O0 -fno-inline -Wall -g -include/yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0/autoconf_vsbConfig_quote.h -D_C99 -D_HAS_C9X -D__vxworks -D__VXWORKS__ -D__RTP__ -D__ELF__ -D__WRS_NO_DIRECT_TLS_ACCESS_FROM_RTP_TO_SHARED_LIB -I/yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0 @/yow-build40-lx1/bkuhl/workspace/VSB/mk/_vsbuinc_cmdllvmBOOST -D_VX_CPU=_VX_SIMLINUX -D_VX_TOOL_FAMILY=llvm -D_VX_TOOL=llvm -D_nq_VSB_CONFIG_FILE=/yow-build40-lx1/bkuhl/workspace/VSB/h/config/vsbConfig.h -I/yow-build40-lx1/bkuhl/workspace/VSB/share/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/system -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -D_VSB_PUBLIC_HDR_DIR=/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -I. -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_TIMER_STATIC_LINK=1 -DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -DTEST_FLOAT -I".." -I"../libs/math/include_private" -I"../libs/math/test" -c -o "../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o" "../libs/math/test/test_poisson.cpp" ../libs/math/test/test_poisson.cpp:454:39: error: reference to 'real' is ambiguous typedef policy<discrete_quantile<real> > P1; ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:689:21: note: candidate found by name lookup is 'real' inline long double real(_Lcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:543:14: note: candidate found by name lookup is 'real' inline float real(_Fcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:397:15: note: candidate found by name lookup is 'real' inline double real(_Dcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0/boost/math/policies/policy.hpp:225:4: note: candidate found by name lookup is 'boost::math::policies::discrete_quantile_policy_type::real' real, ^ ../libs/math/test/test_poisson.cpp:454:39: error: unknown type name 'real' typedef policy<discrete_quantile<real> > P1; ^ ../libs/math/test/test_poisson.cpp:454:45: error: expected a type typedef policy<discrete_quantile<real> > P1; ^ 3 errors generated. ...failed clang-vxworks.compile.c++ ../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o... -------------------------------------------------------- I'd like to contribute a pull request to resolve this. But I'd like some guidance; is a simple change that qualifies real acceptable. using namespace boost::math::policies; - typedef policy<discrete_quantile<real> > P1; + typedef policy<discrete_quantile<boost::math::policies::real> > P1; typedef policy<discrete_quantile<integer_round_down> > P2; Or is this something that should be added with #ifdef __VXWORKS__

2 1

Re: [boost] Boost.Signals deprecation and removal
by Mike 22 Jun '18

22 Jun '18

> Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: > [1]Boost.Signals is no longer being maintained and is now deprecated. [...] No mention of removal. The documentation even says > If you have existing [2]Boost.Signals-based code, it **will continue to work**, but consider moving to Boost.Signals2.Â Best Mike References 1. http://Boost.Signals/ 2. http://Boost.Signals/

6 6

[release] 1.68.0 closing for major changes next week
by Marshall Clow 21 Jun '18

21 Jun '18

One week from tomorrow master will closed for major changes. Upcoming dates: * 27-Jun: Boost 1.68.0 closed for major code changes * 4-Jul: Boost 1.68.0 closed for beta * 11-Jul: Boost 1.68.0 beta 1 * 1-Aug: Boost 1.68.0 closed for release * 4-Aug: Boost 1.68.0 release -- The Boost Release Team

2 1

[Build] Create test with shared library linked against current Boost link-variant
by Alexander Grund 18 Jun '18

18 Jun '18

Hi, I discovered a severe bug in Boost.Serialization and am trying to contribute a test to the test suite to reproduce that behavior. I have a minimum example which runs into this (see also https://stackoverflow.com/questions/50064617/order-of-destruction-for-stati…) but I'm having trouble getting that into the Jamfile. What I need: 2 shared libraries linked against the currently tested Boost link-variant and link those into an executable not linked against Boost. So testcase a) would be against Boost-Shared and b) against Boost-Static. But in all cases the libraries itself must be shared. What I have: lib multi_shared_1 : multi_shared1.cpp ../build//boost_serialization : <link>shared ; lib multi_shared_2 : multi_shared2.cpp ../build//boost_serialization : <link>shared ; ... [ test-bsl-run test_multi_shared_lib : : multi_shared_1 multi_shared_2 ] Problem: This links against Boost-Shared even with "./b2 link=static" My best approach so far is to change "../build//boost_serialization" to "../build//boost_serialization/<link>static" but then I cannot test testcase a) (Boost-Shared) anymore. Also it does link other Boost-Libraries (filesystem, system) shared, not static. Furthermore I'd need to add `-fPIC` to the cxxflags of the boost libraries. This is minor as it can be done in the `.travis` file but I'd rather have it in the Jamfile so it is not missed in other test-environments. How can I achieve this? I'm not to familiar with the Jamfiles so this is basically all I could find so far. Thanks, Alexander Grund

1 1

[container] [flat_map] Sub-optimal behavior when utilized with std::less<>
by Viktor Sehr 16 Jun '18

16 Jun '18

It seems to me that neither boost::flat_map nor boost:flat_set with a custom comparator such as std::less<> behaves like std::set/std::map. This results in unnecessary allocation, in difference from std::map/set when used with a std::string as key for example Example: // Please note that I pretend that "dummy" is large enough to make the std::string utilize the heap. auto set = std::set<std::string, std::less<> >{}; auto n = set.count("dummy"); // No conversion from const char* to std::string auto flatset = boost::container::flat_set<std::string, std::less<> >{}; auto n = flatset.count("dummy"); // const char* is converted to a std::string before comparison, thus resulting in an unnecessary allocation. Is this a known issue intended to be resolved? Looking at the code of STL (which ever version ships with Visual Studio), find, count etc has been extended with template key types in addition to the regular key_type using an "is_transparent" trait: template<class _Other, class _Mycomp = key_compare, class = typename _Mycomp::is_transparent> size_type count(const _Other& _Keyval) const { _Keyval _Paircc _Ans = equal_range(_Keyval); return (_STD distance(_Ans.first, _Ans.second)); } Best regards /Viktor Sehr

4 4

Interest in (parts of) type_safe, e.g. Boost.StrongTypedef?
by Jonathan Müller 15 Jun '18

15 Jun '18

I've been working on https://github.com/foonathan/type_safe for the past 20 months or so. What started as an experimenting ground for type safe programming facilities quickly turned into a general mix bag of utilities. However, it became my most popular project, so there is something in there people find really useful. And with that multiple approached me wanting to have it added to Boost, so here I am. I do realize that not all of it is suited for Boost: some of it has overlap with existing libraries (e.g. optional/variant), some of it has better implementations elsewhere (e.g. improved integer types) and some of it is to novel/experimental (e.g. stuff like constrained_type). But there are some things that could be useful for Boost. I'm mainly thinking of the strong typedef facility. I plan on splitting the library up into multiple parts anyway (see also https://github.com/foonathan/type_safe/issues/82) so please let me know whether there is anything you'd like to see being prepared for Boost. Thanks, Jonathan

3 2

[rational] release (optimized) builds are failing unit tests
by James E. King, III 12 Jun '18

12 Jun '18

I am adding CI to Boost.Rational and the unit tests are failing for different levels of optimization on different compilers. Before I dig into it further, does anybody have any idea what this might be? https://github.com/boostorg/rational/issues/18 See issue for error output. Ubuntu Bionic gcc unit test succeeds: -O0, -O1 unit test fails: -O2, -O3 boost@17b66a9efac4:/boost/libs/rational/test$ g++ --version g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0clang unit test succeeds: -O0 unit test fails: -O1, -O2, -O3 boost@17b66a9efac4:/boost/libs/rational/test$ clang++-6.0 --version clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin To reproduce, try: boost@17b66a9efac4:/boost/libs/rational/test$ ../../../b2 toolset=clang variant=release rational_test I am using the ubuntu bionic docker container to do the build in. See boostorg/boost#184 <https://github.com/boostorg/boost/pull/184>

1 0

[release] 1.68.0 deadline for new libraries approaching
by Marshall Clow 12 Jun '18

12 Jun '18

One week from tomorrow master will closed for new libraries. Upcoming dates: * 20-Jun: Boost 1.68.0 closed for new libraries and breaking changes * 27-Jun: Boost 1.68.0 closed for major code changes * 4-Jul: Boost 1.68.0 closed for beta * 11-Jul: Boost 1.68.0 beta 1 * 1-Aug: Boost 1.68.0 closed for release * 4-Aug: Boost 1.68.0 release -- The Boost Release Team

1 0

meta/libraries.json question
by Antony Polukhin 11 Jun '18

11 Jun '18

Hello, I see that I can specify "std": [ "proposal" ], in meta/libraries.json. What are the other options? Can I write "с++17" instead of "proposal" (for Any and Variant)? -- Best regards, Antony Polukhin

1 0

boost::winapi and Windows CE 7 and Windows Mobile 6
by Vyacheslav Lanovets 07 Jun '18

07 Jun '18

Hello, I am having big trouble migrating from 1.65.1 to 1.67 in VS2008 for CE platform. We already have quite a few patches for boost we reapply on every update. Boost 1.67 added more issues here and there, and among them the winapi library. On our old CE 7.00 I have winnt.h file where the second branch get selected. #if (defined(_M_MRX000) || defined(_M_IX86) || defined(_M_ALPHA) || defined(_M_PPC) || defined(_M_IA64)) && !defined(MIDL_PASS) #define DECLSPEC_IMPORT __declspec(dllimport) #else #define DECLSPEC_IMPORT #endif Therefore, WINAPI functions are not imported but is linked via corelib.lib library. So when I compile my code I see 3>D:\Dev\boost167\boost/winapi/semaphore.hpp(48) : error C2375: 'CreateSemaphoreW' : redefinition; different linkage 3> C:\Program Files (x86)\Windows CE Tools\SDKs\DS-200i\include\ARMv4I\winbase.h(3189) : see declaration of 'CreateSemaphoreW' To make things worse in Windows Mobile 6 SDK half of API is imported and half is not (goes through corelib.lib). Visual Studio 2008 installer includes WM6 SDK. And in the file C:\Program Files (x86)\Windows Mobile 6 SDK\PocketPC\include\ARMV4I\winbase.h there are functions not prefixed with WINBASEAPI. The solution would be to have 2 new defines instead of BOOST_SYMBOL_IMPORT in boost::winapi. On CE 7 both would be empty, on WM 6 one would be __declspec(dllimport) Regards, Vyacheslav

4 3

Yap formally accepted into Boost
by Louis Dionne 04 Jun '18

04 Jun '18

Dear Boost, This message is to announce that Yap (which had been conditionally accepted [1]) is now accepted into Boost, since the conditions for acceptance have been met. The conditions for acceptance were: - Improve the documentation to satisfy Brook Milligan and myself (done) - A single macro for symmetric binary operators (done in https://github.com/tzlaine/yap/issues/22) - Get rid of external dependencies checked into repository (done) - Boost.Build (done in https://github.com/tzlaine/yap/issues/52) Congratulations Zach! Louis Dionne Review manager for Boost.Yap [1]: https://lists.boost.org/boost-announce/2018/03/0540.php

2 1

Re: [boost] [Algorithm] contains(v, 1)
by Jean-Philippe DUFRAIGNE 04 Jun '18

04 Jun '18

On 5/31/18 3:14 AM, Olaf van der Spek via Boost wrote: > Hi, > > vector<int> v; > contains(v, 1); > > This doesn't work as contains expects two ranges (AFAIK). > Is there some other function that's usable for this purpose? > Should contains support a value for argument 2? > > Gr, > Hi, This algorithm exists: boost::any_of_equal https://www.boost.org/doc/libs/1_67_0/libs/algorithm/doc/html/the_boost_alg… Thanks; Jean-Philippe

2 1

[outcome] v2.1 progress report
by Niall Douglas 04 Jun '18

04 Jun '18

Dear Boost, Two months after you accepted Outcome into Boost, I am pleased to say that I believe that all the known bugs and very substantial source refactoring recommended by the peer review have been implemented (detailed changelog is appended below). What remains is a few months of maturing in real world use as all this severe refactoring needs to be tested outside a test suite, and of course the documentation which I don't intend to start work on until the autumn. The Boost edition has, obviously, received a major upgrade and it is now 100% "Boost native" in that it uses Boost.System and Boost.Exception now. The test suite for the Boost edition exclusively tests the Boost native edition, and it all passes. Outcome (both standalone and Boost editions) now can handle both Boost and std types freely intermixed as you see fit. A new "lite" single header edition exists which drags in virtually no system headers, and is hideously low impact on compile times as a result. ABI and API stability have been dumped to git repo with scripting to check the current library against the frozen dumps. This edition should make the corporate crowd very pleased. Very little should appear to have changed from the outside. Code written for v2.0 ought to, more or less, compile and work as before with v2.1. I would appreciate whatever help the Boost community can give in helping to test this edition. I expect new bugs to have been introduced given the severe source code refactoring, and new dual support for Boost and std as equals. My gratitude in advance. Niall --- ## v2.1 in progress [[project]](https://github.com/ned14/outcome/projects/1) - Boost edition is now 100% Boost, so defaults for `result` and `outcome` are `boost::system::error_code::errc_t` and `boost::exception_ptr`. Moreover, the test suite in the Boost edition now exclusively tests the Boost edition. One can, of course, freely use the standalone edition with Boost, and the Boost edition with `std` types. - Renamed ADL discovered customisation point `throw_as_system_error_with_payload()` to `outcome_throw_as_system_error_with_payload()`. - [#135](https://github.com/ned14/outcome/issues/135) - Added much clearer compile failure when user tries `result<T, T>` or `outcome` where two or more types are identical. Thanks to Andrzej Krzemieński for suggesting a technique which combines SFINAE correctness with the remaining ability for `result<T, T>` etc to be a valid type, but not constructible. - [#67](https://github.com/ned14/outcome/issues/67) - Fixed one of the oldest long open bugs in Outcome, that the noexcept unit tests failed on OS X for an unknown reason. - [#115](https://github.com/ned14/outcome/issues/115) - Outcome did not construct correctly from `failure_type`. - Inexplicably outcome's error + exception constructor had been removed. Nobody noticed during the Boost peer review, which is worrying seeing as that constructor is needed for one of the main advertised features to Boost! - [#107](https://github.com/ned14/outcome/issues/107) and [#116](https://github.com/ned14/outcome/issues/116) - `operator==` and `operator!=` now become disabled if the value, error and exception types do not implement the same operator. - Relatedly, both comparison operators simply didn't work right. Fixed. - [#109](https://github.com/ned14/outcome/issues/109) - `swap()` now has correct `noexcept` calculation and now correctly orders the swaps to be whichever is the throwing swap first. - Added reference dump of v2.1 ABI so we can check if ABI breakage detection works in the next set of changes, plus Travis job to check ABI and API compatibility per commit. - [#124](https://github.com/ned14/outcome/issues/124) - `OUTCOME_TRY` is now overloaded and selects `void` or `auto` edition according to input parameter count. - [#120](https://github.com/ned14/outcome/issues/120) - Fix generation of double underscored temporary variables in `OUTCOME_UNIQUE_NAME`, which is UB. - [#110](https://github.com/ned14/outcome/issues/110) - Separated `result` from its hard coded dependency on the `<system_error>` header. - Renamed `result` and `outcome` to `basic_result` and `basic_outcome`. - Renamed `result.hpp` into `basic_result.hpp`. - Moved `<system_error>` and `<exception>` dependent code into new `std_result.hpp` and `std_outcome.hpp` header files. - Added `boost_result.hpp` and `boost_outcome.hpp` which use Boost.System and Boost.Exception (these are `result.hpp` and `outcome.hpp` in the Boost edition). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 1

[beast] How do I select un-DEPRECATED interfaces?
by Brian Kuhl 04 Jun '18

04 Jun '18

Hi Experts, I’m working with an EAR release of VxWorks 7 with llvm v5.0 and VxWorks’ first C++14 STL ( Dinkum v700) and Boost v 1.67 ( Yes, the RTOS world moves slowly) I’ve gotten a clean compile of Beast with #define BOOST_BEAST_ALLOW_DEPRECATED #define BOOST_COROUTINES_NO_DEPRECATION_WARNING But I’m having trouble locating the logic that’s choosing these deprecated interfaces for me? Could someone point out the relevant logic? Many Thanks, Brian Kuhl Senior Manager – Information Development Wind River

2 1

[Algorithm] contains(v, 1)
by Olaf van der Spek 03 Jun '18

03 Jun '18

Hi, vector<int> v; contains(v, 1); This doesn't work as contains expects two ranges (AFAIK). Is there some other function that's usable for this purpose? Should contains support a value for argument 2? Gr, -- Olaf

5 13