- Boost - lists.preview.boost.org

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Wed, Nov 14, 2018 at 8:35 AM Edward Diener via Boost-users < boost-users(a)lists.boost.org> wrote: > On 11/14/2018 11:06 AM, Marshall Clow via Boost-users wrote: > > On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > wrote: > > > > toolset arch compile Link Execute > > msvc-8.0 32 FAIL X X > > msvc-8.0 64 FAIL X X > > msvc-9.0 32 X X X > > msvc-9.0 64 X X X > > msvc-10.0 32 X X X > > msvc-10.0 64 X X X > > msvc-11.0 32 X X X > > msvc-11.0 64 X X X > > msvc-12.0 32 X X X > > msvc-12.0 64 X X X > > msvc-14.0 32 FAIL X X > > msvc-14.0 64 FAIL X X > > msvc-14.1 32 X X X > > msvc-14.1 64 X X X > [snip] > Lots of errors with msvc-8.0: > [snip] > This is a result of a change in MPL for VC++8. I will back out this change. > Appreciated. Please test locally, and we'll watch the bots. (Looks like we have two MSVC-8 bots) -- Marshall

1 0

What is status of Boost.Sync?
by Mateusz Loskot 13 Nov '18

13 Nov '18

Hi, The library docs docs say it's been in Boost since 1.55. Boost master has no submodule for it. Boost develop has submodule for it If Sync was removed, why it is still in develop? If Sync was added, hence it is in develop, why the docs mention 1.55 and why it is not in master? What is the status of this thing? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Boost Test Matrix - no clang release builds?
by James E. King III 12 Nov '18

12 Nov '18

I was putting together some additional testing for a library and my CI jobs were failing in release mode. I was able to reproduce the issue locally. On examination of the boost test matrix however I was unable to see the same failures. When I dug into it a little bit more, it looks like the clang linux build jobs only build the default variant (debug), and therefore will not catch release-mode optimization issues when running the unit tests. Here's one of the job details: https://www.boost.org/development/tests/develop/teeks99-02-dc6-17-Docker-64… Given this matrix is the last line of defense before code is merged from develop to master, I'd suggest that the build jobs should all be targeting variant=release instead of variant=debug. The former directly impacts a release, and the latter does not. - Jim

4 3

[hash] Missing boost::hash_value for std::forward_list
by Alexander Zaitsev 11 Nov '18

11 Nov '18

Hello. Recently I found that boost::hash_value has no overload for std::forward_list. Who can tell me - why? Is there any reason and/or limitation? Thank you. -- Best regards, Alexander Zaitsev

1 0

[config] std::uncaught_exceptions
by Lorenzo Caminiti 11 Nov '18

11 Nov '18

Hello all, std::uncaught_exception (singular) is deprecated in C++17 and will be removed in C++20. std::std::uncaught_exceptions (plural) should be used instead. Will Boost.Config have a macro to detect if std::uncaught_exceptions is supported or not by the current compiler? (For example, Boost.Contract implementation uses std::uncaught_exception and it will need to use std::uncaught_exceptions on C++20 compilers instead.) Thanks. --Lorenzo

2 3

[release] 1.69.0 closed for Beta
by Marshall Clow 10 Nov '18

10 Nov '18

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > You can preview the release notes at: <http://www.boost.org/users/history/in_progress.html> Thanks, -- The Boost Release Team

1 0

[release] many release notes pending
by Joaquin M López Muñoz 09 Nov '18

09 Nov '18

Just a heads up about the existence of many umerged lib-specific release notes at: https://github.com/boostorg/website/pulls I seem to remember this same issue happened in 1.68. Maybe some other protocol is needed for handling release notes. Best Joaquín M López Muñoz

6 10

Suggestions for TMP/function introspection problem?
by Hans Dembinski 09 Nov '18

09 Nov '18

Hi all, I am trying to figure out how to solve an introspection problem since a few days, and I am not making progress. I could use some help, it is for boost.histogram. Maybe what I want is not possible... Here is my problem. I have some classes A, B, ... which have some overloaded methods, let's call them `foo`. struct A { void foo(int, char); void foo(bool, int, char); }; struct B { void foo(double); void foo(bool, double); }; I need a way to detect how many arguments the shorter methods has. If the shorter method is foo(Ts...), the longer method is always (bool, Ts...). This is guaranteed. I do not know what Ts... is, it can be anything. I cannot use boost::callable_traits, because an overloaded member function cannot be fetched by name using t = boost::callable_traits::args_t<decltype(&A::foo)>; // fails, overload is ambiguous Can't I match the member function with a template of the form something(bool, Ts...) somehow? Any ideas? Best regards, Hans

2 4

Re: [boost] Boost.Build check to see if cxxflags flag is supported?
by Peter Dimov 09 Nov '18

09 Nov '18

> Note 4: > > This should probably be a feature, like <position-independent>on, which > toolsets translate to -fPIC as appropriate. ... which will fix the case where a shared library uses a static library, but -fPIC is not applied to the static library.

3 3

clang-win, (Thin)LTO this time
by degski 08 Nov '18

08 Nov '18

Starting new thread. Substantial progress has been made towards the goal of compiling Boost with Clang/LLVM (clang-cl.exe, targeting MSVC). The latest PR in this respect by Peter has achieved this. The next step is to be also able to use lld (lld-link in case of clang-cl.exe targeting MSVC) to generate the Boost-libs (static/dynamic). The main interest, IMO, is to be able to use LTO (Thin or Full), which is not possible without the use of LLD. A secondary benefit appears to be faster link times (info from the lld manual). In order to build static ThinLTO-enabled libs, it suffices to pass <compileflags>-flto=thin in the project jam file. The archiving, though, needs to be done with lld-link.exe, passing /lib as the first option (this way it will act as lib.exe, while being able to handle the llvm-byte-code [lib.exe finds the so generated .obj-files to be corrupt]). At consumption time of the libs, lld-link needs to be used for linking. Hacking clang-win.jam:156 to: toolset.flags clang-win.archive .LD $(cond) : "\"C:\\Program Files\\LLVM\\bin\\lld-link.exe\"" /lib ; achieves this goal. I would like to ask (probably Peter) to have a look into whether this can be achieved "the proper way", i.e. to programmatically set that particular line to the required value for this use-case. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 13