- Boost - lists.preview.boost.org

Requesting formal review for (Boost) LEAF
by Emil Dotchevski 10 Jan '19

10 Jan '19

LEAF is a small C++11 error handling library (the acronym stands for Low-latency Error Augmentation Framework). Features: - Header-only, NO dependencies. - No dynamic memory allocations. - Associate objects of arbitrary types with any failure — when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming. Official documentation: https://zajo.github.io/leaf. LEAF is designed for use in low-latency environments without exception handling, but it also works with exception handling; in that case it is a better, more optimal replacement for Boost Exception. This link can be helpful for refactoring existing Boost Exception code: https://zajo.github.io/leaf/#boost_exception.

5 9

async_read SEGFAULT
by hh h 09 Jan '19

09 Jan '19

I use one io_service in one process to run two servers A and B each has its own port, own context and SSL configuration to accept inbound connections. Although both A and B have boost::asio::deadline_timer, but I think there is only one thread is running: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fe0bc0 (LWP 31204) "ssl_connection" 0x00007ffff4a690a3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:84 The problem I got: - If I started only one server A, it worked just fine for both async_read and async_write. - If I started both servers A and B, even B was in idle, server A could sometime be crashed after receiving and responding just one message, then crashed at next async_read in the first second, it was more stable if it did not call async_write. SEGFAULT: Fault address=0x55b3700d00cf, #4 0x000055555557f98a in boost::asio::detail::task_io_service_operation::complete (this=0x55555584adc0, owner=..., ec=..., bytes_transferred=0) at /usr/include/boost/asio/detail/task_io_service_operation.hpp:38 #5 0x0000555555581f82 in boost::asio::detail::task_io_service::do_run_one ( this=0x555555814710, lock=..., this_thread=..., ec=...) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:372 #6 0x0000555555581ab4 in boost::asio::detail::task_io_service::run ( this=0x555555814710, ec=...) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:149 #7 0x000055555558221f in boost::asio::io_service::run (this=0x7fffffffe150) at /usr/include/boost/asio/impl/io_service.ipp:59 It seems that async_write and async_read messed up, but that problem was intermittent, especially when the server A passed first second, it could be running for hours for doing consequent many async_read and async_write simultaneously. It was only one thread, what could cause that problem? Thank you.

2 11

b2 --exec-prefix=...
by Peter Dimov 09 Jan '19

09 Jan '19

Our "b2 --help" documentation says --exec-prefix=<EPREFIX> Install architecture dependent files here. Default: <PREFIX> --libdir=<LIBDIR> Install library files here. Default: <EPREFIX>/lib and bootstrap.sh also supports --exec-prefix and when given, records it in project-config.jam. But it doesn't work and has never worked. Only --prefix is honored, --exec-prefix is simply ignored. I think that we should bring the documentation and the actual behavior in sync, either by making --exec-prefix work as documented, or removing it from the documentation. Which one should we do? Comments?

5 4

Boost wiki - revised Boost guidance for authors on Warnings - RFC
by Paul A. Bristow 08 Jan '19

08 Jan '19

As promised at the end of a long (hijacked!) thread on 'Warnings' http://boost.2283326.n4.nabble.com/Current-Guidance-on-Compiler-Warnings-td… starting from a query by Brian Kuhl of Wind River on Boost's policy on compiler warnings, I have spent some time revising the previous guidance document on Trac that I edited many years ago. This was a long and tedious task as Markdown, as most conveniently used on Github, is rather different from the mark-up language on Trac, leaving me slightly in fumble mode :-( I have made some updates en passant, but there is still much to do updating for the much improved granularity of warning suppression and perhaps more about other code improvement tools like Lint, UBSan. The overall structure leaves a lot to be desired, but I don't want to put any more work into this without some encouragement that it will prove useful. I have posted the result of my efforts on https://github.com/boostorg/boost/wiki/Guidelines:-Warnings and I am as promised I am starting this new thread on warning for your comments, corrections, condemnations etc. HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 2

[cmake] Pull request announcement - update
by mike.dev＠gmx.de 07 Jan '19

07 Jan '19

I think it is time for an update on this issue. #################################################### # TLDR: There are now ~25 boost libraries that can be directly used in a cmake project via the add_subdirectory & target_link_library - workflow. And I want to encourage library maintainers to comment/merge outstanding PRs or make similar additions to their libraries themselves. ################################################### # A summary what that thread was about: In September last year I was informing the mailing list that I was about to make a bunch of PRs adding a set of minimal CMake files to various boost libraries. Their sole purpose was to enable the following workflow from within a cmake project: add_subdirectory( <path-to-boost-libfoo-directory> ) target_link_library( my_app Boost::libfoo ) Without needing b2 or the boost super project for that matter (although support in the super project would be very welcomed) For that, the cmake file in libfoo has to - provide the target Boost::libfoo - attach the dependency information for Boost::libfoo - attach the proper include directory for Boost::libfoo - if necessary, build libfoo with whatever toolchain and compile flags the parent cmake project defines - if necessary, attach any necessary compile definitions to Boost::libfoo Although things like running the unit-tests or provide and install target can be added by any library maintainer (and some have done just that) it is not part of my PRs. ################################################### # What is the current state. For a quick overview, I uploaded a picture of the boost dependency graph (code based on boostdep) that shows which libraries Have a cmake file in their root and which don't [1]. So far, about 25 libraries have gained cmake files as part of this effort (not all from me). And of course there are a couple of libraries that Already used cmake before I started my efforts, but AFAIK, most of them can not be used in the above mentioned work-flow. Of course, there remains a lot to do, but at least progress is happening and we now have fitted almost all "foundational" libraries , so from here on out, the pace should increase. Currently, I have 7 outstanding PRs and I would ask the Respective maintainers to comment on them as soon as they can find some spare time, as further PRs are blocked on them. Even if the PRs get completely rejected, I at least know for which part of boost I should no longer pursue this quest and/or find a workaround. Finally a big thanks to all maintainers that added such cmake files on their own. Best Mike [1] https://gist.github.com/Mike-Devel/46d04409d6ae6053861706e3ad91e4dc Explanation for the linked picture: It shows the boost dependency graph (generating code based on boostdep). - Green libs already have a cmake file in their root directory - Yellow libraries don't have such a cmake file, but all their dependencies have one, so one could be added and most likely there is already a PR for that - Red libraries have at least one direct or indirect Dependency that lacks a cmake file, so I consider Them "blocked" for now.

4 3

A class for embedded friendly callbacks.
by Mikael Rosbacke 07 Jan '19

07 Jan '19

Greetings. I'm Mikael Rosbacke and new to this list. The last couple of months I've been writing on a class for storing callbacks to different forms of callables (member functions, functors, free functions). The main focus has been to make it suitable for embedded work with small footprint and dependable exception and heap behavior. The code can be found on github: https://github.com/rosbacke/delegate It has reached a stage where I'm getting sort of 'done'. I feel it could be useful to a wider audience so I would like to get some feedback about if this is suitable for that and if it is worth starting a new branch for possibly adapting it to boost for inclusion in some future version of boost. Any feedback is appreciated. Cheers, --- Mikael Rosbacke

2 2

Should pass boost::asio::io_service by raw pointer or smart pointer?
by hh h 07 Jan '19

07 Jan '19

Hi, In many examples and even implementations, programmers like to pass boost::asio::io_service by raw pointer: MyClass::MyClass(boost::asio::io_service &io_service) : myRawIoService(io_service) {} Will this cause issues to pass raw pointer for large size of classes, should it be replaced by passing smart pointer: MyClass::MyClass(const std::shared_ptr<boost::asio::io_service> &io_service) : myIoService(io_service) {} Thank you.

5 9

Is there interest in an "iofiber" library?
by Vinícius dos Santos Oliveira 06 Jan '19

06 Jan '19

I have written a completion token for Boost.Asio that is a little more advanced than plain ASIO's spawn featuring abstractions such as join(), detach() and even interrupt(). I'd like to know if there is interest in seeing this library merged as part of Boost. https://vinipsmaker.github.io/iofiber/ (there is also a mutex and a semaphore, but these are undocumented as of now and were poorly ported from the previous token supporting abstractions and need rework) Boost.Fiber integration with ASIO is problematic: https://github.com/boostorg/fiber/issues/102#issuecomment-263558882 Default Boost.Asio yield token will do as long as you don't need communication between fibers. When primitive communication is necessary, you can work around it by exploiting the completion token protocol. In fact, after having rolled my own solution, I eventually was made aware of Peter's solution (which he rolled on his own independently) which was incredibly similar to my solution: https://github.com/equalitie/ouinet/blob/a2afaf9932c8a23434d1f0a10be06fc407… If you need anything more advanced such as careful strand integration, join, or interruption API, you'll just have to roll your own token. That's what I end up doing after working around ASIO's token for many months. There was also a recent request by Vinnie to turn Boost.Coroutine 1 deprecation warning off. This separate library would be an alternative (although it is still a far from review-ready). -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

3 4

Re: [boost] Skipping regression builds for unsupported toolsets
by Nikita Kniazev 05 Jan '19

05 Jan '19

> > How can I 'tell' regression builders to skip building GIL > where required C++ version is not supported? Add requirements to you tests Jamfile, something like: import config : requires ; project /boost/gil/test : requirements [ requires cxx11_constexpr cxx11_decltype cxx11_template_aliases cxx11_variadic_templates ] (those checks come from Config library which most likely you are pulling already in your CI builds). I noticed that some libraris specify "std" in libraries.json, for example: > - Any: "std": [ "c++17" ] > - Ratio: "std": [ "proposal" ] > What is the purpose of these? > Is this respected by regression builds? I doubt those do anything. IIUC `libraries.json` is used only for https://www.boost.org/doc/libs/ list generation.

2 1

Skipping regression builds for unsupported toolsets
by Mateusz Loskot 05 Jan '19

05 Jan '19

Hi, The regression builds report unreloved issues for number of libraries: https://www.boost.org/development/tests/develop/developer/issues.html In particular, for Geometry and GIL those issues happen on msvc-8.0. For GIL, specifically, this is due to the fact GIL now requires C++11. How can I 'tell' regression builders to skip building GIL where required C++ version is not supported? I noticed that some libraris specify "std" in libraries.json, for example: - Any: "std": [ "c++17" ] - Ratio: "std": [ "proposal" ] What is the purpose of these? Is this respected by regression builds? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0