- Boost - lists.boost.org

[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

Making copyright holders easier to parse
by Giovanni Mascellani 07 Aug '19

07 Aug '19

Dear Boost developers, I am one of the Debian developers maintaining the Boost package in Debian. As part of packaging policy, we want the copyright status of each file in Debian packages to be documented, which includes at least the name of the copyright holders and the license of that particular file. As you can believe, this is rather complicated for Boost, since there are a lot of files with many copyright holders. I started to use the tool bcp, which among other things is able to collect such copyright information. My clone is available here[1]. However, bcp often is confused by the inconsistent style of how copyright holders are listed in different files, so it required a lot a manual fixing. For example, sometimes copyright years are written before the name, sometimes after, sometimes they're absent; names are sometimes separated by commas, sometimes by newlines, maybe even sometimes by nothing. Sometimes there are spelling mistakes or casing inconsistencies between names, or inconsistent institutions' names. Bcp has some complicated regular expression to overcame all these differences, but the result is brittle at its best. [1] https://salsa.debian.org/gio/boost-copyright Since I am doing this manual work anyway, I might as well update the Boost files so that their copyright headers are more consistent and easy to parse, and then I could submit you patches for having them fixed in the Boost official repositories. My question is: are you interested in this kind of patches? Of course I would still go through the ordinary patch submission procedure. I am just asking if this kind of patches would be well received or not. To better illustrate what I mean, let me consider a few examples (the chosen files are completely random); file libs/log/include/boost/log/exceptions.hpp currently has: > /* > * Copyright Andrey Semashev 2007 - 2015. > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I might change this to: > /* > * Copyright: 2007-2015 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ File libs/atomic/include/boost/atomic/fences.hpp has: > /* > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > * > * Copyright (c) 2011 Helge Bahmann > * Copyright (c) 2013 Tim Blechmann > * Copyright (c) 2014 Andrey Semashev > */ I might change this to: > /* > * Copyright: 2011 Helge Bahmann > * Copyright: 2013 Tim Blechmann > * Copyright: 2014 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I hope these examples illustrate my intention. I think that having more easily parsable copyright holders could be useful for Debian, for Boost and for Boost adopters which should properly care about the licensing of the libraries they use. Thank you, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

14 23

Expansion of Boost.Algorithm
by ATHARVA VEER 06 Aug '19

06 Aug '19

Greetings to all! I am planning to expand Boost.Algorithm by including more of general purpose algorithms to it. But since I don't know the future roadmap of the module, I cannot suggest changes right now. Also I have couple of algorithms in my mind that I think would be great if they are part of Boost but I don't know if Boost.Algorithm is the right place to include them. So I was wondering if anyone is willing to mentor me (as in review my work and suggest changes before merging) and we could discuss what we could include in Boost.Algorithm or appropriate module to include them. Brief about myself:- I am junior year college student and I have some experience working in open-source. I haven't contributed to Boost before but have used Boost libraries in day to day life. Thank you!!

1 0

Boost 1.71.0 Beta 1 and Quantlib 1.15
by Cg K 06 Aug '19

06 Aug '19

Gentlemen, Please read this message from Quantlib Dev board <https://sourceforge.net/p/quantlib/mailman/message/36730686/> In short, I was not able to compile Quantlib 1.15 with Boost 1_71_0_b1_rc1 I was able to compile it with 1.70 with some creativity. See here. <https://sourceforge.net/p/quantlib/mailman/message/36732240/> I have a complete list of the errors and messages. It is some 36 pages long and thought it best not to attach. If anyone wants it I will gladly send it to them privately. kaucher(a)gmail.com

4 5

[quickbook] build errors on master
by Raffi Enficiaud 05 Aug '19

05 Aug '19

Hi, I just merged develop to master and I have quickbook errors on my CI (see errors below). The exact same code compiled at 27. July 2019 at 13:47:19 CEST. Does anyone know something about this? Thanks, Raffi 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:18: error: no member named 'directory_iterator' in namespace 'boost::filesystem'; did you mean 'directory_entry'? 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ~~~~^ 05-Aug-2019 21:44:37 ../../../boost/filesystem/path_traits.hpp:48:9: note: 'directory_entry' declared here 05-Aug-2019 21:44:37 class directory_entry; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:61: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:70: error: use of undeclared identifier 'dir_e' 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:161:16: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 ++dir_i) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:162:26: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 fs::path f = dir_i->path().filename(); 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:170:41: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 if (fs::is_regular_file(dir_i->status())) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:178:42: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 if (!fs::is_regular_file(dir_i->status())) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 7 errors generated.

2 1

[release] 1.71.0 post-beta merges
by Michael Caisse 05 Aug '19

05 Aug '19

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> Thanks, -- The Boost Release Team

7 17

Expansion of Boost.Algorithm
by ATHARVA VEER 04 Aug '19

04 Aug '19

Greetings to all! I am planning to expand Boost.Algorithm by including more of general purpose algorithms to it. But since I don't know the future roadmap of the module, I cannot suggest changes right now. Also I have couple of algorithms in my mind that I think would be great if they are part of Boost but I don't know if Boost.Algorithm is the right place to include them. So *I was wondering if anyone is willing to mentor me (as in review my work and suggest changes before merging) and we could discuss what we could include in Boost.Algorithm.* Brief about myself:- I am junior year college student and I have some experience working in open-source. I haven't contributed to Boost before but have used Boost libraries in day to day life.

1 0

Boost.Accumulators regression in Boost 1.71 beta 1 on VC++17/19
by Luigi Ballabio 04 Aug '19

04 Aug '19

Hello, the attached minimal file fails to compile on VC++17/19 when using Boost 1.71.0b1. It compiles successfully with Boost 1.70.0. I also attach the compiler errors. Cheers, Luigi

1 1

ASIO socket wired observation
by JH 03 Aug '19

03 Aug '19

Hi, I have been using asio tcp socket on desktop Ubuntu for years, but I have never seriously run interface connections in a LTE embedded system, here is what I have observed wired thing: - Client initialized TCP socket connection to remote server, the connection was established. - Client sent data to server via Internet every one minute, all good. - Somehow, the LTE connection dropped, there was no any network connection available, but the client keep sent messages, there was no error about the network connection, the message obvious could not go Internet, it accumulated in the RAM, the original each message size was 79 bytes, the size was accumulated became 52790 bytes, it kept going for ever until I terminate the client program. ....... Send message size: 52790 Send message size: 52869 Send message size: 52948 ..... Is it normal behavior of ASIO socket or what I did wrong here? Appreciate your insight tips to fix this problem to trig client socket error not keeping sending message going no way. Thank you. Kind regards, - jupiter

2 1

How safer to use boos::shared_from_this() from derived class inherited from based class?
by JH 02 Aug '19

02 Aug '19

Hi, I have a derived base class: class Base : boost::enable_shared_from_this<Base> { public: Base(); virtual ~Base(); virtual boost::shared_ptr<Base> SharedFromThis(void) {return shared_from_this();} private: } class Derived : public Base { public: Derived(); ~Derived(); // boost::shared_ptr<Derived> SharedFromThis(void) {return boost::static_pointer_cast<Derived>(shared_from_this());} private: }; Applications are sharing the derived class, it can either use shared_ptr<Derived> or shared_ptr<Base> by calling the SharedFromThis(), three options: (1) Don't define derived class own SharedFromThis(), always call Base SharedFromThis() to pass shared_ptr<Base> as Derived shared_ptr, the reference count will be shared_ptr<Base>. (2) Define derived class its own SharedFromThis() and pass shared_ptr<Derived> to applications: boost::shared_ptr<Derived> SharedFromThis(void) {return boost::static_pointer_cast<Derived>(shared_from_this());} That one cannot be virtual as conflicted to Base SharedFromThis(), the reference count will always be boost::shared_ptr<Derived> (3) Mixed both boost::shared_ptr<Derived> and boost::shared_ptr<Base> in applications, that could be a bad option to cause segmentation as one shared_ptr could be ended before another shared_ptr. Which option will be safer? Thank you. Kind regards, - jupiter

2 2