October 2018 - 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

[asio][coroutine] forbid_suspend blocks
by Vinícius dos Santos Oliveira 07 Aug '19

07 Aug '19

I've implemented a dumb linter using Python + clang API that allows you to mark certain blocks as “atomic in respect to coroutines” using C++11 attributes. Usage example follows: void f() { int yield; g(yield); [[bt::forbid_suspend]] { // Comment this call to make linter accept the code g(yield); t(); } } You can change bt::forbid_suspend to another identifier by tuning settings on the beginning of the script. The prefix forbid was inspired by Rust's linters[1] as you cannot disallow the linter from inside the forbid_suspend block. Some limitations follow: - A suspend point is identified by looking references to any id equals to yield in the last argument passed to function calls. It means that yield[ignored_ec] and alike will be correctly identified, but it needs to be named yield and it needs to be the last argument to the function call. - I haven't found a way to extract attributes related to COMPOUND_STMT nodes with clang API, so I manually look for token gaps and do a simple regex. It means you cannot use macros to [[bt::forbid_suspend]] as the macro won't be expanded. - You better call the script with '-x c++' and also ' -I/usr/lib/clang/5.0.1/include'. Like I've said in the beginning of the email, it's a *dumb* linter, which means it doesn't try to handle all cases. Therefore, I don't hope to do many changes to it or maintain it to work against newer releases of clang and I'm only uploading it to gist (not fullblow Github): < https://gist.github.com/vinipsmaker2/d930fbe5b7597432b021effe618da171>. It should also be easy to hack as it is very small. I'm releasing the linter under public domain. Enjoy. I have been using fibers in a daily basis on the last months of my job to solve networking problems on a gateway project. Some of the technologies I use are: - Boost.Asio and its spawn function. - A few custom synchronization primitives for the fibers (e.g. mutex, semaphore). - Eventually I'll have to write a custom spawn function that returns a joinable handle so I can kill the usage of a fiber::barrier in a few places. I've been using the linter for about a week already and looks fine. My use case are: - To prevent iterator invalidation in regions accessing shared variables. - To guarantee events order in algorithms that handle races (cannot yield while task YYY hasn't finished). The project I use it in is not an open source project, so I cannot talk much more about it. Also, I don't claim my solution is original. I wouldn't be surprised if the very same solution exists in the wild (please let me know if you know of a similar approach). This is not a new problem. It is know for some time. For instance, in P0171, Gor Nishanov noted this same problem: “In coroutines the suspend point is clearly marked with await, which tells the reader that something unusual happens in this function and allows the reader, for example, to confirm whether the lifetimes of the objects of interest align with the lifetime of the coroutine or not, whether some locks need to be acquired to protect some concurrently accessed data, and whether some locks need to be released before the execution reaches the suspend point.” — <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html>, 2015 However, the solution he presented was to manually examine whole blocks of code without help from the compiler. I argue that the solution he presented is as error-prone as manually looking for exit paths that don't free acquired resources in languages lacking RAII. And I've been spoiled too much by RAII. Furthermore, I take this comment of his with highly suspicious look: “Since we are on the subject of maintenance nightmares, we would like to offer a conjecture that the absence of the await in P0114 is a likely source of many maintenance nightmares. Without a syntactic marker to signal to the person reading the code that something funny is going on, it is impossible to tell whether the following code is correct or not” — http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html If I had to give a vote to the proposal he was defending or Chris' proposal, I'd probably have chosen Chris'. [1] https://doc.rust-lang.org/reference/attributes.html# lint-check-attributes -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

Non-ASCII Path Names in Repo
by Tom Kent 25 May '19

25 May '19

In the last few days we've had a non-ASCII path name added to the repo: tools/boostdep/test/utf8-test-ßµ™∃ Which came with commit 8893d1c57951a [1] I noticed this because a python 2 script (calling shutil.copytree) I had running on windows that copied the repo around started to fail. I've long needed to update that script to python 3, and am working on this. However, I wanted to point this out to the list so we could discuss if there are any other ramifications of having a non-ascii path. I vaguely remember some discussion about something like this in the past, but couldn't find it via search. If this is already a settled topic, that's great. Tom [1] https://github.com/boostorg/boostdep/commit/8893d1c57951a4a83705ed203005576…

2 1

Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by Bjorn Reese 12 May '19

12 May '19

On 06/28/18 21:03, ThePhD via Boost wrote: > 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 Does out_ptr have other use-cases than C interoperability?

7 14

[test] unit test command-line handling
by Stefan Seefeld 22 Mar '19

22 Mar '19

Hello, this is a question concerning the Boost.Test framework. I'd like to pass command-line arguments to my tests, and I'm unsure of how to proceed. I have found https://www.boost.org/doc/libs/1_68_0/libs/test/doc/html/boost_test/adv_sce…, which shows how to access the command-line programmatically, but that's declared obsolete, and it's also lacking some important info, such as how I should handle the argv vector. Are there any examples that demonstrate this use case ? Specifically: * What (non-deprecated) API can I use to access command-line arguments during test initialization ? * How does my own handling of command-line arguments interact with Boost.Test's own command-line argument handling ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 8

Reminder: 1.69 closes for major changes Wednesday
by Marshall Clow 10 Dec '18

10 Dec '18

Upcoming dates: * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team

4 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

"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

[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

interest in a flag library
by Masse Nicolas 05 Nov '18

05 Nov '18

Hi all, This is the first time I post on this mailing list :). I'm posting because i'd like to know if people would be interested in a library to treat enum types as flags. I find that's something which is lacking in the language since the introduction of strongly typed enums, and I've since written some code in order to do this. So far I've seen some discussion on this mailing list about that, but it doesn't seems that any library have been written yet. So do you think it is worth the effort of porting and documenting my code so that it can integrated into boost, or not? Regards, Masse Nicolas. PS: For those interested, the code consists of a flag class, and overloads operators like '|' or &. It can be used like this: enum struct option : uint { none = 0, first = 1, second = 2, third = 4, forth = 8 }; static constexpr flags<option> var1 = option::first; static constexpr flags<option> var2 = option::second | option::third; static constexpr auto var3 = var1 | var2; /* type will be resolved into flags<option> */ static constexpr auto var4 = option::first | option::second | option::third; /* works too */ int main() { std::cout << var1 << std::endl; std::cout << static_cast<uint>(var2) << std::endl; /* note that static_cast<int> won't compile since the underlying type is uint */ std::cout << (var3 & option::forth) << std::endl; std::cout << (var3 == var4) << std::endl; return 0; }

8 9