August 2018 - Boost - lists.preview.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

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

clang-win, again
by Peter Dimov 31 Oct '18

31 Oct '18

Has anyone succeeded in getting clang-cl.exe working under b2? I've installed llvm-6.0.1, added it to PATH, put using clang-win : : : <compatibility>vc14 ; in my user-config, and what I get is: C:\boost-git\develop\libs\smart_ptr\test>b2 toolset=clang-win sp_interlocked_test warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (b2) is 2015.07.00 warning: Boost.Build core (at C:/boost-git/develop/tools/build/src) is 2018.02-git C:/boost-git/develop/tools/build/src/tools\msvc.jam:1087: in set-setup-command *** argument error * rule virtual-target.from-file ( file : file-loc : project ) * called with: ( : /C:/boost-git/develop/libs/smart_ptr/test : object(project-t arget)@129 ) * missing argument file C:/boost-git/develop/tools/build/src/build\virtual-target.jam:970:see definition of rule 'virtual-target.from-file' being called C:/boost-git/develop/tools/build/src/tools\msvc.jam:652: in clang-win.compile.c+ + C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\virtual-target.jam:902: in execute C:/boost-git/develop/tools/build/src/build\virtual-target.jam:821: in class@acti on.actualize C:/boost-git/develop/tools/build/src/build\virtual-target.jam:332: in actualize- action C:/boost-git/develop/tools/build/src/build\virtual-target.jam:518: in actualize- no-scanner C:/boost-git/develop/tools/build/src/build\virtual-target.jam:142: in class@virt ual-target.actualize C:/boost-git/develop/tools/build/src/build\configure.jam:258: in try-find-build C:/boost-git/develop/tools/build/src/build\configure.jam:396: in find-builds-raw C:/boost-git/develop/tools/build/src/build\configure.jam:455: in configure.find- builds C:/boost-git/develop\boostcpp.jam:734: in boostcpp.deduce-address-model C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\property.jam:144: in property.evaluat e-conditionals-in-context C:/boost-git/develop/tools/build/src/build\targets.jam:1087: in evaluate-require ments C:/boost-git/develop/tools/build/src/build\targets.jam:1121: in common-propertie s2 C:/boost-git/develop/tools/build/src/build\targets.jam:1017: in targets.common-p roperties C:/boost-git/develop/tools/build/src/build\targets.jam:1313: in class@basic-targ et.generate C:/boost-git/develop/tools/build/src/build\targets.jam:812: in generate-really C:/boost-git/develop/tools/build/src/build\targets.jam:784: in class@main-target .generate C:/boost-git/develop/tools/build/src\build-system.jam:797: in load C:\boost-git\develop\tools\build\src/kernel\modules.jam:295: in import C:\boost-git\develop\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\boost-git\develop\boost-build.jam:17: in module scope

9 74

[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

Tools to manage multiple repositories effectively?
by James E. King III 09 Oct '18

09 Oct '18

Hello, I am looking for tools that would allow me to create a portal and/or monitor the following properties of boost repositories. I am in the CMT and at least one fix that was in develop never made it into master for the 1.68.0 release, so I want to be able to see, at a glance, information about the boost repositories I care about in one place. There are about 20 repositories I regularly participate in now so a portal to show what I need to worry about would be useful. 1. How far behind is master (with respect to develop)? This would help identify which repositories are behind develop. Useful for ensuring things get into a release. 2. How many open pull requests? 3. How many new pull requests (within the last week)? 4. How many updated pull requests (within the last week)? 5. How many open issues? 6. How many new issues (within the last week)? 7. How many updated issues (within the last week)? "week" could be configured, perhaps month, or "since I last visited". Anybody know of any good tools or perhaps an existing site that can do this for a multi-repository solution? Thanks, Jim

3 2

[all] Request for out of the box visibility support
by Antony Polukhin 09 Sep '18

09 Sep '18

I'd like to draw attention to a problem with Boost binaries for Linux. There's an awesome -fvisibility=hidden flag for Linux compilers that improves load times, performance, size of binaries and reduces the chance of symbol collisions. More info at https://gcc.gnu.org/wiki/Visibility . Unfortunately, most of the Boost libraries do not set it by default: - atomic - chrono - container - context - contract - coroutine - date_time - exception - fiber - filesystem - graph - graph_parallel - iostreams - locale - mpi - program_options - python - random - regex - signals - system - test - thread - timer - type_erasure - wave Moreover minority of the above libraries just do not work with the flag. Users just can not run ./b2 cxxflags="-fvisibility=hidden" because there's a chance that some library could stop linking. Actually things are even more ugly. Linux distributions usually do not tune the build flags for each package so at least Debian based distributions build Boost with default flags. Users get suboptimal builds. If you're a maintainer of one of the above libraries *please do* the following steps: * Make sure that all the public symbols are accordingly marked with appropriate BOOST_SYMBOL_* macro. Instruction is available here: https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/boo… * Turn on the visibility=hidden by default: * by adding <target-os>linux:<cxxflags>"-fvisibility=hidden" to the Jamfile if you do not care much for antique compilers (Example https://github.com/boostorg/stacktrace/blob/819f2b1c861dec7530372a990ecabab… ) * by using a more advanced technique for detecting the flag availability (For example see https://github.com/boostorg/math/blob/develop/build/Jamfile.v2#L20 or https://github.com/boostorg/log/blob/develop/build/Jamfile.v2#L24 ) P.S.: I would appreciate any comments or updates on the feature request. P.P.S.: Log, Math, Serialization (and Stacktrace) libraries already use that flag by default. Many thanks! -- Best regards, Antony Polukhin

10 33

[range] #11202: boost.sort header conflicts with boost.range header
by Steven Ross 07 Sep '18

07 Sep '18

https://svn.boost.org/trac10/ticket/11202 has been sitting for years. The "using range::sort" causing the namespace pollution needs to be deleted, and then everything depending on that inside boost needs to be fixed. This will break people dependent on the namespace pollution, but that's the only way to clean it up. Is anyone willing to take on this cleanup? Is there a good way to identify cross-library dependency breakages in situations like this so they can be fixed?

10 20

Trac
by Robert Ramey 07 Sep '18

07 Sep '18

Could we agree to stop using the Trac system? The github issues/pr system is much more functional. I propose we close the trac system to new issues - be of course leave it available for reference. Robert Ramey

21 57

Guidelines on copyright notice maintenance
by Mateusz Loskot 06 Sep '18

06 Sep '18

Hi, The license guidelines [1] include instructions on "How should Boost programmers apply the license to source and header files?" Unless I've missed it, there seem to be lack of guidelines about how to maintain (existing) copyright notices. I don't aim to resurrect the old lengthy thread from Sept 2015 on validity of copyright notices. In that thread, however, some guidelines or conventions were expressed: [2] "because copyright is only claimed for changes meeting a certain threshold of originality" [3] "It's up to those people to add a line if they so decide. Copyright only covers expressions of creativity." Those suggests, there seem to be common understanding on if/how/when it is recommended or even necessary to update copyright notice in a source file of a Boost library. Wouldn't it be helpful to captured those as guidelines in the BSL FAQ. Would there be someone knowledgeable about it and willing to make the update or at least explain it here? (I will make it into HTML and PR to boostorg/website) I understand David and Beman, primary authors of the page [1], may no longer be available. [1] https://www.boost.org/users/license.html [2] https://lists.boost.org/Archives/boost/2015/09/225565.php [3] https://lists.boost.org/Archives/boost/2015/09/225570.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[ublas] Supporting DNNs with Tensors/Multidimensional Arrays
by Cem Bassoy 06 Sep '18

06 Sep '18

Gsoc <https://summerofcode.withgoogle.com/organizations/4507228564881408/> 2018 just ended one week ago and we had many successefully completed student projects <https://github.com/BoostGSoC18>. I was responsible for adding tensor support to Boost.uBLAS for primarily supporting multilinear algebra operations in the field of numerics. The wiki description along with the implementation can be found here <https://github.com/BoostGSoC18/tensor>. Similar to Boost.multi_array <https://www.boost.org/doc/libs/1_68_0/libs/multi_array/doc/index.html> the runtime-reshapable tensor data structure is parametrized in terms of number of dimensions (rank/order), dimension extents, data type, layout (first- and last-order) and storage type. The first two are runtime-variable. I am also about to add subtensor (view/handle of a tensor) along with multidimensional iterators for convenient algorithm implementation. It is yet not as flexible as GSL's multi_span <https://github.com/Microsoft/GSL/blob/master/include/gsl/multi_span>: does not yet support static rank and dimensions. However, basic generic tensor operations (contraction/transposition/reshaping/...), including a nice syntax for Einstein's summation convention with placeholders, using C++17 features are provided. The operations are evaluated using expression templates (not smart yet). Similar to the tensor <https://eigen.tuxfamily.org/dox/unsupported/group__CXX11__Tensor__Module.ht…> framework of Eigen, that is used by tensor flow <https://github.com/tensorflow/tensorflow>, the tensor data structure in Boost.uBlas could be taken for implementing deep neural networks or higher-order statistics I think. I am not sure if the C++ community would appreciate if Boost has some form of basic operations for building *deep neural networks* (DNNs). I would like to ask 1. if it make sense for boost to support basic operations for DNNs? 2. what are the obligatory, necessary basic operations for creating DNN building blocks? 3. if there are any additional data structure parameters that needs to be added for (efficiently) supporting DNNs? Best, Cem

3 5