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

[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

Boost.Build check to see if cxxflags flag is supported?
by James E. King III 07 Nov '18

07 Nov '18

I'm looking for an example for how I could check to see if "-fPIC" is supported for the compiler as part of project requirements. In some recent PRs that include building a static library which then gets included in a shared library, code needs to be built with "-fPIC" on supported platforms/toolsets. There is some code in gcc.jam to do this if the overall link mode is shared (note: this code is not in clang.jam!), but in this case the overall link mode is static, and a Jamfile wraps the result in a shared library, so the directives in gcc.jam are not applied. So at the top level Jamfile, I want to add a project requirement that basically says, "if the compiler supports <cxxflags>-fPIC then use it". Thanks, Jim

3 2

Deadline for 1.69.0 beta extended
by Marshall Clow 07 Nov '18

07 Nov '18

The deadline for closing the master branch for the 1.69.0 beta has been extended until Friday, November 9th. The final release date has not been changed. -- Marshall (who is at a WG21 meeting all week)

1 0

[release][predef] Permission to merge to master..
by Rene Rivera 07 Nov '18

07 Nov '18

I have a change that adds some missing version information for Cygwin OS detection < https://github.com/boostorg/predef/commit/62a50d3892789076272b771f560a419b9…>. Can I merge that to master? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

"peer reviewed" - Rights and responsibilities of maintainers
by Alexander Grund 07 Nov '18

07 Nov '18

I'm having trouble with a maintainer of a boost library over a PR and am seeking for clarification. Background (may be skipped): A bug was introduced into the library which I noticed in one of "my" (company) projects leading to a reproducible crash. However the scenario is not that common (although others have the same problem) so it wasn't noticed earlier. I analyzed the problem and created a minimum working example to reproduce this and then opened a PR with a fix. The maintainer did not comment on this for multiple months so given it IS complicated, I factored out additional PRs with tests I created to show the problem, so each PR is fairly small. In the result there were PRs with tests that failed on travis and the fix-PR which included the test-PRs and the fix and succeeded on travis (and all other CIs) and users reported success using this PR. Still no response from the maintainer on any PR. He then added an own test claiming to be enough, while I (as the author of the original tests) knew it wasn't as e.g. it didn't fail. (so what's it worth then?) Furthermore he added a commit changing unrelated stuff and ADDITIONALLY changing code I touched in the fix claiming that it would be the essence of my patch and fix the problems. Again I (as the author of the original patch) know that this is not true especially as the test-PRs still fail with his patch applied. So my point/problem is: Is the maintainer allowed to simply do changes as he wishes without any review at all? My expected procedure is: - Someone creates a PR - Maintainer (and optionally the community) reviews (and comments on) it - It eventually gets merged or rejected with comments why OR: - Someones else (including the maintainer) creates a contra-PR fixing the same problem - That author explains, how and why this fixes the same problem and why it is superior to the original PR - This gets reviewed and either PR gets merged Arguments were made, that this doesn't apply to accepted boost libraries as e.g. "it's [the maintainers] heads that got chopped off if something gets broken". I would challenge this by the simple example at hand: This boost library IS broken and it crashes MY application (and others). But I see no heads rolling. Furthermore: If the maintainer is allowed to patch and change as he wants without ANY review, how can Boost still be called "peer reviewed"? My trust in Boost stems from the extensive review a library has to undergo before it is included in Boost. If afterwards no review is happening or reviews are actively avoided (as in the current example), then the older a Boost library gets, the less trust I would have in it as more and more unreviewed changes get included. So again: What is the Boost course on reviews of existing libraries and the statement on the rights and responsibilities of maintainers? Thanks, Alexander Grund

15 52

[parameter] Go C++11 and above only, or keep C++03 support?
by Cromwell Enage 06 Nov '18

06 Nov '18

Hi, everyone. The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-depe…>--the following Boost libraries known to use Boost.Parameter would also become C++11: Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2 I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary. Cromwell D. Enage

14 37

[testing] Lots of spurious test runners
by John Maddock 05 Nov '18

05 Nov '18

There are rather a lot of test runners that fail all tests due to setup errors: sandia-gcc-5.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-5.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-gcc-6.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-6.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-intel-16.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-16.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-16.0 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-17.0 /bin/sh: line 1: icpc: command not found teeks99-02-dc3.1-11-Docker-64on64 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:2194:2: error: no type named 'type' in 'std::enable_if<false, void>' (and more errors from <functional> - the compiler appears to be unable to handle the std lib headers so I'm not sure what the point of testing it is?) igaztanaga-develop-gcc-3.4c++03 cc1plus.exe: error: unrecognized command line option "-fvisibility-inlines-hidden" cc1plus.exe: error: unrecognized command line option "-fvisibility=hidden" Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 3